If Error Throw New Brick

Finished, but just barely...

2011-11-20T21:38:00.000-08:00

Here's the proof:

~~http://dl.dropbox.com/u/8791050/Magecrawl%20-%20Arena%20.1.zip~~

This version has the correct SDL libraries bundled so you don't need the SDL dev libraries installed.

http://dl.dropbox.com/u/8791050/Magecrawl%20-%20Arena%20.11.zip

Tomorrow I'll have a legitimate posting with instructions and the like. I just wanted to get something up tonight.

You'll need the .NET 4 runtime or the equivalent mono. You probably need the SDL development libraries installed as well. I'll try to clean things up tomorrow and shove out a better release.

Go go 4DRL.

Hello...is this thing on...

2011-11-19T20:13:00.000-08:00

I just received a comment wondering what the status of anything I've been working on, since I haven't posted in forever. This was ironic, since I was thinking about making a post tomorrow anyway.

The wife was out of town for a business conferences, so I decided to see what I could hack out in two after-work timeslots and Saturday/Sunday.

You might notice the stubbed out "action bar" at the bottom, but I have a lot working. I've "stolen" chunks of code from previous "iterations" of the game, but the "core" is all new.

It's written in C# and using SDL C#. My goal was to get something playable by end of the day tomorrow, so I've kept many things simple (but functional).

Things working so far:

Turn based movement with a "party" of player characters and various enemy monsters
Line of Sight and Pathfinding
"Animations" done in a way that for once makes me not want to cry
AI decision making is done off the UI thread to keep the game responsive.

Things to finish by tomorrow "hopefully"

Melee/Ranged combat with animations and targetting
"Skills" of some basic type
Multiple different monster types
Different "rounds" in the arena

Wish me luck on my 4DRL.

Magecrawl-Arena status update

2011-04-23T10:59:00.000-07:00

I'm going to try to try to create something like Doryen Arena using python, seeing how things go. I figured I'd post a status update:

Project started 8 days ago, with about an hour of coding a day roughly. I'm through stage 5 of this, which includes:

GUI - Using public domain graphical tiles from Crawl Stone Soup, found here, I have a scrollable map with variable tiles (not every dirt tile is the same), that persist.
Physics - I have a simple physics engine that includes walls (that one can't walk through), and doors one can open.
Keybinding - Arbitrary key mapping (mouse support to come!)
Serialization - Save/Load support.

Compared to Magecrawl itself, it seems somewhat pathetic a feature list. However, I'm enjoying poking around in python between games of Portal 2 and Rift.

Source can be found here if you are curious.

Clever Python Hacks Part II - Serialization

2011-04-23T10:49:00.000-07:00

Serialization is Magecrawl is pretty good, however it is somewhat verbose. I write out a giant XML tree with all of the attributes of everything, and parse that in on load. It is about 200 lines of core code, along with about 100 for the map and about another 100 for the player.

Here's what my serialization code looks like in python so far:

    SaveVersion = 1
    def __save(self):
        with open(self.player.name + ".sav", 'wb') as file:
            pickle.dump((self.SaveVersion, self.player, self.level), file)

    def __load(self, filename):
        with open(filename, 'rb') as file:
            fileSaveVersion, player, level = pickle.load(file)
            assert fileSaveVersion == self.SaveVersion
            self.player = player
            self.level = level

I do loose the XML format in exchange for a binary one, but you have to love that simplicity.

Clever Python Hacks Part I - Keymapping

2011-04-20T06:19:00.000-07:00

Keymapping was complicated stuff in Magecrawl. See here for the XML reader(LoadKeyMappings() and HandleKeystroke). It was powerful stuff, using reflection, XML and such. However, I just got 80% of that in a four liner today:

def load_key_mapping():
    globalDict = {}
    exec(open("KeyMapping").read(), globalDict)
    return globalDict["KeyMapping"]

This function loads the given file as a python script and executes it, then sucks out the KeyMapping dictionary. The KeyMapping script looks like this:

import pygame

KeyMapping = \
{
    pygame.K_UP : 'Up',
    pygame.K_DOWN : 'Down',
    pygame.K_RIGHT : 'Right',
    pygame.K_LEFT : 'Left',
}

I get a simple dictionary of button presses to string, and I can switch off those later. The only concern I have is people sharing KeyMapping files and people doing stupid things in them. However, right now I'm now that concerned, as this is stupidly simple and works great.

Spinning Up The Time Machine

2011-04-19T16:47:00.000-07:00

So, I'm still playing with python. Not sure I'm going to write an entire roguelike in it, but figured I'd hack out to the step 4 (walking around a room) on the 15 steps to a roguelike.

I noticed the number of files/lines of code seemed to be much smaller than I remembered, so I pulled up the equivalent submission in magecrawl.

The python copy looks like this:

While the magecrawl looked similar to this (this was from a few weeks later, similar idea though)

Here is the comparision (excluding test code). This isn't comparing to the map generator picture above, just the walking around an empty room.

Python - 3 source files, 127 lines of code.
C# - 13 source files, 503 lines of code.

Much of that difference comes from the verbosity of C#. Some of it comes from the use of interfaces in C# compared to duck typing in python. The rest comes from an effort to implement the minimum needed and keep things simplier.

As a side note, pygame is pretty awesome. I might pull in libtcod for line of sight and pathfinding, but since I want "tiles" graphics, pygame made that crazy easy.

Has it been 6 months already?

2011-04-15T10:33:00.000-07:00

Wow, I can't believe 6 months slipped by that quickly. Between work and my personal life, I seem to have lost track of time (and stopped updating this). Eitherway, I'll try not to let that happen again.

I've picked up programming for fun again, but so far not on magecrawl. I still want to finish it or something like it, but I've come to realize something about myself and the projects I work on as a hobby. I find things fun that are different from what I work on while at work. While I was working in C/C++, C# was fun to work on; now that I use it 8+ hours a day, not so much now. The Silverlight front end was fun until I started wrestling with Silverlight at work.

I'm playing around with Test Driven Development and Python these days. It is kind of funny that I have more test code in my little project than actual lines of code, but I hear that is how things are supposed to be.

Once I get something a bit more presentable I'll post more about it. I just wanted to get back in the habit of blogging again.

Learning OpenGL, slowly...

2010-11-07T14:22:00.000-08:00

So I've burned a few hours trying to learn OpenGL. I'm using C#, accessing OpenGL via OpenTK. The tutorials here are great, but a bit out of date. After much frustrations, I found that ramblingcoder picked them up and converted them to C#.

Frustrations on programming languages

2010-11-03T20:51:00.000-07:00

So, I'm honestly a bit demotivated to work on Magecrawl. Part of it is that I'm in the middle of porting it to Silverlight as a way to get a tiles version with little work that will work on Windows/Mac/Linux. Then this week, I come across these articles.

While it isn't like they are canceling Silveight, their "change in focus" and the fact that Mono is currently two major versions behind has me a bit worried. I don't want to sink another 20+ hours fixing things up, and then in a year or two have to move to another UI layer. I also don't want to loose being able to work on it on my Mac, and right now I'm in that boat.

More fundamentally, I'm frustrated that there doesn't seem to be a "good" way to do cross platform UIs for my game. I'm going to rattle though the programming languages I know or are good options. None of them right now seem to be a good fit.

C# - Silverlight: Only Mac/Windows right now. Linux is an unknown period of time away. A bit worried about its future, but probably best option right now.

C# - libtcod: Works everywhere, but no tiles UI.

C# - winforms - Yeah, it might technically work on Mac/Linux, but there are licensing concerns that make ppl not want to install it.

C# - GTK# - Doesn't look native on ANY platform except Gnome.

C/C++ - Any number of frameworks here, QT being the most obvious framework or OpenGL. Ignoring the rewrite aspect, I'd rather not chase memory errors in an unmanaged language when I'm not being paid for it.

python - pygame would be the most logical choice. I don't think I want to write in a dynamically typed language.

objective C - See C/C++ for the unmanaged language type. It also wouldn't work well on Windows/Linux, and I have no clue what GUI framework to use.

Java - Seriously? Swing looks terrible anywhere, and with ~~Sun~~ Oracle trying its best to kill developer uptake, that isn't an option.

In writing this article, I've come across opentk, which appears to be a open gl binding for C#. While I'd have to learn yet another UI framework, at least I know it'd work everywhere...

Status Update - Not dead yet...

2010-10-31T07:43:00.000-07:00

As one might have noticed, my postings the last few weeks have been few and far between. There are a few contributing factors to this decline:

Large amounts of software testing reduce my motivation to come home and work on Magecrawl
Work on a website for my wife's business. {shamelessPlug} Music therapy in Austin, Round Rock, Georgetown {/shamelessPlug}. This involved learning pretty quickly CSS/HTML and Joomla as a CMS.
Starcraft II - I gave in and got it. It is video games goodness distilled into a drug like potency. I am currently playing against Gold level players on 1v1, and I have a pretty mean 4gate rush.

I still haven't given up on Magecrawl. With the testing at work ending and the website up and running, things should be calmer over here. The only hurdle to working on Magecrawl will be not playing SC II...

[Offtopic] Pain in PDF printing on my mac, workaround...

2010-10-19T20:56:00.000-07:00

So, since I spent three hours of my life on this, I figured a post on the internets for other to find was worth writing.

My goal was simple. My wife had created a document in pages and wanted it professionally printed. First attempt was a simple "save as pdf". That failed, as there were tiny inconsistencies when viewed on a PC. I installed adobe reader on my mac and low and behold, they showed up there. I thought PDFs were supposed to look the same everywhere...

Some google research pointed to PDF X-3, which iWorks claims to be able to export. It is apparently a subset of PDF that everyone agrees on. Yes, let that last sentence sink in. PDF, the format that is supposed to look the same everywhere, now has a sub-format to do that job. Eitherway, attempts to export the document fail with a generic "can not create PDF-X3" error. Apparently this is a long standing bug with iWorks where some complicated documents throw that error. No fix, no work around. This is starting to sound like bloody Linux...

Alright, next approach is using the "ColorSync Utility" to create a filter. People online seem to saying this sometimes works. After launching the beast, I find out that it apparently fails to save resolution settings at all. This means when I filter wife's document through it, it comes out looking like 1990 smacked it upside the head, low resolution and all...

The solution I have come up with is the 500 lb (226 kg for my metric friends) sledgehammer of a solution.

Open iWorks. Save document as PDF that won't work in adobe.
Open PDF in preview, File->Save As.
Selection JPG, change quality to full and DPI to 500.
Send that 15 meg JPG to the printer...

crawl-tiles announcned, a "public domain" source of graphical tiles

2010-10-07T05:32:00.000-07:00

My work on getting the crawl tiles public domain is complete. Here is the "press release" that I posted to R.G.R.D:

I am happy to announce the first release of the crawl-tiles project
(http://code.google.com/p/crawl-tiles/).

Crawl Stone Soup (http://crawl.develz.org/wordpress/) has a beautiful
set of graphical tiles based on rltiles (http://rltiles.sourceforge.net/) with many extensions and modifications.

Until now, they were under the "Crawl license", derived from the
Nethack license and thus unusable by most projects.

A majority of the developers/artists have signed off their work into
the public domain (CC Zero license technically), and thus their work
is now redistributable and usable by other projects.

I have packaged that work up into a form easily consumable by other
projects, and placed it on the crawl-tiles download page.

Feel free to take a look, use them in your new project. If you do so,
please consider noting in your game where they came from.

Chugging along on Magecrawl for SL...

2010-09-30T16:49:00.000-07:00

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...

2010-09-28T06:53:00.000-07:00

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

2010-09-20T21:05:00.000-07:00

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!

2010-09-19T17:02:00.000-07:00

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

2010-09-18T20:56:00.000-07:00

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

2010-09-14T19:04:00.000-07:00

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"

2010-09-07T20:14:00.000-07:00

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 :)

I can has magecrawl on the internets?

2010-08-31T21:32:00.000-07:00

So it might not look like much, but that's magecrawl running in a web browser! Levels generated, items created, monsters waiting for time to start ticking. The only thing missing is drawing and control.

My good friend Ben inspired the idea and helped implement some the magic.

Roughly the magic entails removing all references to libtcod from the game engine. That way, we can load all that code inside a web browser via silverlight, (which can't load native code). I "ported" this code from libtcod:

Shadowcasting Line of Sight
A* Pathfinding
Bresenham Line Generation

"Porting" could be described as the twisted application of force needed to move C code to compile and run in C#. Since none of them used pointer math too heavily, it was reasonable to attempt. The code looks ugly for C# code, but it works.

In theory, it should even save and load! I can use my same serialization code, just point it to "isolated storage" and away we go.

Obviously, a lot of work is needed to make it a real game frontend. But the fact that I could even get this far (and not have to rewrite everything in flash) is pretty awesome.

A simple way to reduce memory usage of structs/enums in Dictionaries

2010-08-28T08:53:00.000-07:00

I can't take credit for this tip, it was pointed out here.

As pointed out here, by default if you use a struct or an enum inside a dictionary, you will alloc objects every time you access the dictionary to box/unbox things. For example this will allocate both a Point an object to box it in:

var squareLookup = new Dictionary<Point, SkillSquare>()
squareLookup[new Point(0,0)] = null;

I ran into issues because I used something like this for drawing the skill tree, and when you scrolled we hit the dictionary a huge number of time.

The linked hint suggests doing something like:

public class PointEqualityComparer : IEqualityComparer<Point>
    {
        public static PointEqualityComparer Instance = new PointEqualityComparer();

        public bool Equals(Point x, Point y)
        {
            return x == y;
        }

        public int GetHashCode(Point obj)
        {
            return obj.GetHashCode();
        }
    }

var squareLookup = new Dictionary<Point, SkillSquare>
    (PointEqualityComparer.Instance)
squareLookup[new Point(0,0)] = null;

With this simple change, a profiled run of scrolled went from over 70% of all allocated memory being Points to so few it wasn't even broken out as an entry. This increased performance by a huge amount.

Testing - Baby Steps

2010-08-27T07:01:00.000-07:00

I just committed the first nunit tests for magecrawl this morning. Automatic testing has been on my "nice to have, but not now" list for multiple releases. The reason in short is that writing tests isn't fun, which in some regards is a stupid reason, and in others is understandable (this project is my hobby, not my second job).

My first step into testing was 11 tests, testing the generators (Item, Monster, Map). They simply just poke each generator public API thousands of times, looking for a hang or crash. During development, I ran into a significant number of issues related to this, so this was a "low hanging fruit".

In the future, I'm planning on writing more tests, testing the game engine itself and more of the external libraries. However, I'm currently demotivated enough that I want/need to work on other more interesting things.

Modularization - The joys

2010-08-24T06:50:00.000-07:00

Modularization, the process of breaking a monolithic software component into multiple separate components. To be honest, it isn't very much fun. For a year or so, I did a lot of it at work, enough so that my wife recognizes the word and knows it isn't very much fun. This is what I did all weekend.

The first question is why I would spend a significant portion of the weekend doing something I admit isn't fun as part of my "hobby". The truth is that in most hobbies there are parts that one does not enjoy. Runners don't always enjoy getting up early to run, some parts of video games are called "grinds", and practicing a skill or instrument isn't often fun.

Magecrawl during development had a few modular boundaries established early on, between the GameEngine and the UI, that has been honored. However, the "GameEngine" component has grown to include much of the games logic, enough that I felt for testability (more on that in further posts) and understandability, things had to be broken up.

Here is a picture of what I currently have:

A bit of explanation, everything that isn't MageCrawl.exe, GameUI, Interfaces, and Utilities used to be in GameEngine. Here's a rough idea of what everything does:

Utilities - Low level stuff, like the Point class, Preferences, and helper classes for saving and finding types at run time.
Interfaces - These are interfaces that the GameEngine as a whole provide that allow the GameUI and controls to query information about the current game state. Things like IPlayer, IMap, IGameEngine, etc.
GameUI - This is what draws the map, menus, etc.
MageCrawl - This is the game engine proper. It has an implicit dependency of GameEngine via MEF. It kicks everything off and runs the main game loop.
EngineInterfaces - This is a set of internal interfaces the game engine components use to talk about objects everyone needs to know about. For example IGameEngineCore describes the calls to the GameEngine the various modules can use to implement their behavior. For example, those interfaces might expose how to add a status effect to a creature, but to do that you need to know what a status effect is. But status effects live "above" this module, so we create an interfaces that we can expose at this low level, IStatusEffectCore (IStatusEffect is in Interfaces for the GUI).
Items - This guy technically existed last release. It was the newest written code, hence being formed as a separate module. This guy handles creating items and exposing their behavior via Attributes.
StatusEffect - This guy handles short and long term status effects, things like poison, haste, and the like. It acts by using the exposed interfaces in IGameEngineCore and attributes.
Actors - Technically, this module contains monsters (and their AI), along with the Character base class. Characters can wield equipment (Melee for all monsters right now though) and have StatusEffects upon them. Player lives in GameEngine since it has a lot of other stuff (Spells, Skills, etc).
Maps - This was the guy I wanted to pull out. It exposes the map data structures, and the multiple ways to generate maps. Maps place monsters onto them self, and can contain items on the ground.
GameEngine - This is where everything else lives. It handles physics (who can move where, etc), combat (resolve attacks), magic (what does the spell do), and the like.

This is a rough outline of MageCrawl's internal structure. I'll talk about it more in future posts.

libtcod 1.5.1b1 released!

2010-08-21T08:18:00.000-07:00

As many may know, Magecrawl uses libtcod (via libtcod-net) for both graphics and engine support (FOV, LOS, etc). Months ago, I created a SWIG'ed version of libtcod-net, so that I could stop supporting a hand-rolled wrapper. A (beta) release featuring that has now come out.

If you use libtcod via c#, I highly recommend upgrading to the new wrapper, as the old one is deprecated and no new work will be done on it. Also, the new version has OSX versions for both C# and native C/C++ developers.

Get the hotness here.

Iteration 10 - The long road to slices (want to get out and help push)?

2010-08-19T20:48:00.000-07:00

So I've spent this week doing "research" on what next lies in store for Magecrawl.

The first thing I've realized is I now have a good "family tree" for Magecrawl. While Magecrawl isn't developed enough for Crawl to consider it a legitimize offspring, it provides much of the inspiration and root ideas. Things like tactical gameplay, high difficulty, removal of any "grinding" gameplay, and a crazy good auto-explore are all things I aspire to have. Borderlands takes the role of the crazy uncle that rubs of a little bit. It provides such a varied equipment set that playing the game a second (and third) playthrough is fun and interesting. Diablo can be considered one of the grandfather figures. It to me was one of the great dungeon delve games of my youth.

My serious hope is that is the last "iteration" in the series to build up a game engine. Tasks I want to finish to put me in a great place include:

55 open issues in my bug database, mostly minor and a few major features. Some major ones include:

Better monster AI using sounds or smell
Status effects from various schools
Better use of spell effect areas to differentiate the schools
"Typed" damage, just as fire or physical. Resistances to various damage types.

Refactor the GameEngine library into multiple separate libraries, pulling out:

Monster creation/behavior
Status effects
Map creation

Some form of basic integration testing for common operations.
Some form of "arena" for testing the weights of various skill tree nodes, along with the possibility of an awesome screen saver.

So yeah, that's a lot of work. I'm in no hurry to start working a masses of content for a "slice" game, so if it takes me multiple months, it isn't the end of the world.

While I'm still planning on working on Magecrawl (a lot), I feel like I'm in a good place to open up development to others if they are interested. Developing on Magecrawl offers:

A relatively clean/nice C# codebase
Licensed BSD
Works on Windows/Mac/Linux, development is possible on any platform
The possibility to implement high level functionality on a working game, as opposed to starting at square one with an @ walking around the screen (not that there is anything wrong with that)

If this sounds interesting, feel free to contact me at chris dot hamons at gmail dot com.

One last thing, I re-realized how awesome Ascii Dreams is. The "Designing a Magic System" serious of articles and the follow ups should be on the required reading list for any future roguelike developer (or game developer in general). I wish he updated it more often these days, the content is golden.

Release aftermath and thoughts

2010-08-15T16:55:00.000-07:00

So, the new release has been on the interwebs for a few days now. I figured a post with thoughts and future plans was in order.

Some people had issues getting things to run. All of them involved needing either the MSVC 2010 C runtime, or the required mac frameworks. I didn't have them listed on the release page, which has been fixed. In the far future, and installer for magecrawl would be nice to take care of stuff like this.
Very little feedback so far. Maybe the summer and quick release since the last tech demo have something to do with that...
No crashes or savegame corruption reports so far. If people got the game working, it seems to be working fine.

Now that it is out the door, the next question is "now what?". Here are my current thoughts:

Spend the next week collecting game play ideas. My wife pointed out this means I can play video games and call it "research". Magecrawl has matured past the point that calling it a tech demo is becoming a stretch, yet the gameplay is kinda bland. I want to come up with interesting mechanics to make combat more than "jam damage spell, unless I can hit more than one with a bigger spell".
Iteration 10 - Yes, one more. I have a ton of things I need to do, refactors, cleanup, and minor feature polish.
Slice 1- Once I get the base in good shape, I need to come up with a "theme" for my slice. I plan on picking one skill tree, and one/a few map types, and create a lot of content. For example, maybe the arcane tree and ruins maps, or the fire tree and interesting caves. I'll jam it out to be a "full length" game, seriously this time. It might be shallow, but it'll be complete.

Magecrawl Tech Demo III v2 Demo Video

2010-08-12T22:20:00.000-07:00

I've wanted to put together a quick video demo'ing magecrawl for those who want to see the game before downloading it or are having trouble getting started.

I found some decent software which made creating the video easy enough to tackle tonight. If anybody has a pointer to free software that captures screen video and sound and outputs to youtube, please let me know in the comments. Jing, the software I used was easy, but it outputs only to a flash file unless you buy the pro version.

Eitherway, check it out here.

Magecrawl Tech Demo III v2 released!

2010-08-12T20:34:00.000-07:00

I am pleased to announce the release of "Magecrawl Tech Demo III v2". Released two months after the previous Tech Demo III release, it adds features that I wished were part of that release, but not enough I feel to bump it up to number "IV". Highlights of the user visible changes in this release include:

Difficulty that won't melt your face
Concurrent Mac/Linux/Windows release with a single release zipfile
Monster and Items that scale as the game progresses
Long term persistent effects
"Backgrounds" - Starting configurations of skills and items
New skill trees with tons more skills
Smarter AI
New spells, items, and monsters
Bug fixes, and balance fixes

One important note for Linux users, due to a last minute found bug, you will be unable to save unless you add the following string into your Preferences.xml file

< UseSavegameCompression > False < /UseSavegameCompression >

If you run into any crashes, please send the created file "DebuggingLog.txt" to me (chris dot hamons at gmail dot com), along with any save file you have.

One last thing, please seriously consider filing a comment or sending me an e-mail both letting me know you checked out my game and your thoughts. Feedback is the breakfast of champions you know.

Now that I've made you read though all of that, binaries can be found here.

If you haven't run Magecrawl before, here's is what you need installed to make things work:

Windows - .Net 3.5 found here. You might need to 2010 C RTE here.
Mac - Mono found here. You probably need the frameworks SDL, and libpng.
Linux - Also mono found here, however you might want to try a copy installed by your package manager first

Here is how you run Magecrawl:

Windows - Unzip the zip file somewhere, and double click MageCrawl.exe
Mac/Linux - Unzip the zip file somewhere, open a terminal and cd to that directory, and run "mono ./MageCrawl.exe"

"Leaky" stamina, and other "balance" changes

2010-08-11T21:01:00.000-07:00

So, I'm still hacking out changes to make Magecrawl playable.

The major change of the night implements what I hope is a solution to the HP problem I talked about last post. I decided the underlying problem was that going from 100% stamina to 5% stamina involved zero risk. Now, once your stamina goes below a cutoff (currently 80%), there is a chance that some of the damage will "leak" through and apply directly to the underlying health. The chance is inversely proportional to the amount of stamina, so you are much more likely to leak at 20% stamina than 75%. This changes make combat more dangerous overall, but having lots of stamina is still useful but not overpowering.

Other changes I've implemented this week include:

Map generator won't generate a horde of monsters on top of the player starting position
Monsters will notice the player from farther away when they are wearing heavy armor (noise).
Toughness skill will now give health instead of stamina, giving the player the option to "buy" more long term health.
Bug fixes, seriously lots of bug fixes.

The problem with HP...

2010-08-09T21:25:00.000-07:00

I know I've linked to this tv trope, but it is seriously still true in magecrawl. For those not playing along at home, here's what the current system is:

HP is divided into health and stamina. Damage taken is drained from stamina first. Stamina quickly recovers in between battles (assuming you aren't noticed by enemies, you can't rest then). Health damage requires magical healing to fix up. Stamina represents your ability to dodge and block damage enough to get out only with scrapes, bruises, and surface cuts. Health represents actual wounds, while bandaged up enough not to get worse, would normally require weeks to heal on their own.

Let me show you my current problem with an example:

Given 100 health and 60 stamina, you fight a monster which on average does 20 damage per round and takes 4 rounds to kill. Given these stats, you'll exhaust your stamina every fight, taking 20 damage to your health. In five fights, excluding magical healing, you will be dead.

Now repeat with 80 stamina, you on average take little to no health damage, extending the number of one-on-ones to tens or hundreds. If you repeat with 100 or more stamina, you'll extend the theoretical number of battle you can last, but you'll never get close to the "jump" between 60 and 80.

This creates a problem with skills and armor that increase your stamina, at some point you'll be able to solo monsters with no danger of taking semi-permanent health damage. I have a few solutions I'm playing around with:

Make the line between stamina and health less clear cut. When you are at 100% stamina, you are sure any damage you take will be stamina related. As it decrease, there is a higher chance some of the damage goes to your health.

Advantages - Makes battles less one sided, as any blow after a round or two can be lasting.
Disadvantages - Adds a significant luck factor

Make healing stamina take resources

Advantages - Makes every battle matter
Disadvantages - Makes every battle matter, makes it easy to want to micro optimize which isn't fun. Starts to approach the dreaded "food" system in other roguelikes.

Make low stamina penalize certain attributes, such as mp total or time in between actions.

Advantages - Makes stamina damage matter.
Disadvantages - Can snowball, making you more likely to take even more damage. In a game with permadeath, this can get nasty.

Make the stamina and health levels relativity constant (they increase at a rate similar to monsters damage output). Skills/armor give other benefits than more stamina.

Advantages - Makes balancing easier. One you have a good setup, just make sure the rates of growth match.
Disadvantages - Intellectually unsatisfying. Keeps player from feeling any tougher, as at the beginning of the game to the end, the can pretty much only take x hits from a even level monster, where x stays constant.

I'm currently leaning towards the first option, but am unsure right now.

All primary feature work is done for iteration 9, finally...

2010-08-05T07:15:00.000-07:00

So this morning I finished up the last issues I had targeted for iteration 9 in fogbugz. The release isn't yet ready to go out, as I have to play with the numbers to make the game fun/winnable. However, outside of bug fixes, I should be done make code changes for now.

I'm hoping that balancing should be "easy" now that I have filled in tech trees and have a reasonable spread of items, but as I've said before balancing games is hard. Do any other game developers have trouble balancing stats, abilities, items, and such to make a fun game? Any suggestions on ways to make it easier outside playing the game a bunch and make lots of small tweaks?

Skill Trees "Filled Out"

2010-08-04T18:18:00.000-07:00

I decided to spend some time "filling out" a few skill trees, and have simple but complete trees for five sub-trees: Arcane, Fire, Light, Martial, Attributes. Each tree has between 7 and 10 node (except martial which has 37), and each node provides a new skill or improves an existing one. I still at some point need to write descriptions for the martial skills, but beyond that the skill tree is done for this iteration.

Class vs Struct - It actually can matter

2010-08-01T16:16:00.000-07:00

So, the second of my optimization realizations today involves the difference between structs and classes. For those who've been with this blog for awhile, you might remember a post I made half a year ago, here. In that post, I realized that a list of structs uses a lot less memory than a list of classes when each item is crazy small and there are a huge number of them.

Today, I've ran into the inverse. I made Point a struct back when I made that realization, thinking that it was small and therefore memory savings were worth the savings. However, when you stick an item into a dictionary as a key, it apparently makes a copy if it is a struct. It also makes a copy if you query the dictionary with a struct as the key. This meant I could rack up half a million or more point copies by scrolling for 15 seconds in my skill tree. This caused the memory manager to go crazy, and introduce the lag I was seeing. Switching it to a class helped a bunch.

When should you use struct vs when should you use class? Here's my current huristic:

If the item is large or you won't be having a crazy huge number of them - Use class, the possible optimization isn't worth it.
If a large number of the items will be stored in memory in a list - Try struct, as you'll save a pointer sized (4 or 8 bytes) amount for each item.
If you will be using it as a key (or value to a lesser extent) in a dictionary - Use a class, as each query on the dictionary and every access will make a copy.

GetHashCode's preformance really matters if you use it as a dictionary key alot

2010-08-01T15:39:00.000-07:00

Just a quick post about a surprisingly small change that improved performance in magecrawl's skill tree view. I have a custom point class since there doesn't exist one inside c# outside of some GUI toolkits I don't want to force dependencies on.Since I overrode Equals, the compiler told me to override GetHashCode. I did so the naive way:

public override int GetHashCode()
{
    return X ^ Y ^ base.GetHashCode();
}

I have a spot in a tight loop that needs to lookup information based upon its position. I was previously using a List with a where LINQ call, which was insanely slow when I scaled up the number of skills. I figured this out using profiling and changed it to a dictionary. However, it was still too slow, so I read up on GetHashCode more and realized I could change GetHashCode for point to read:

public override int GetHashCode()
{
    return X ^ Y;
}

I didn't keep track of the numbers, but this very visibly made a huge difference. Keep GetHashCode in mind when you have data structures that are used as keys in large dictionaries. A small change can make a big improvement.

Iteration 9 and 10 - The new plan

2010-07-28T16:57:00.000-07:00

So, I'm changing my iteration plans around the release of a video game. Let's just put it out there. Final Fantasy 14 is being released September 30th (early access on 22nd), and I am excited enough to pre-order it. Due to that, and the expected week or two post-release that I won't involve much coding, here's the new plan.

Iteration 9 - Finishes asap. As soon as I get the game balance reasonable, and a spread of items/weapons for the 5 levels of the current dungeon, kick it out of the door. I'm planning on calling it tech demo 3.1 or something similar, just for those readers of the blog who want to see the new stuff.

Iteration 10 - Get as much done in August and September. Things like diminishing returns, school specific debufs, sound drawing monsters, etc. Also get enough of the small features done that the next "iteration" will be more of a "slice". Something where I create more interesting gameplay content and less concern on the game engine.

Generic can be the enemy of progress

2010-07-27T19:45:00.000-07:00

As it was said on coding horror, "a blog without comments is not a blog". Earlier today Jotaf posted a comment on my last post that got me thinking. The post was on my work making changes to the skill tree easier, here's the meat of it:

"Nice, I agree completely, although you must always ask yourself the obvious question: "is it worth it?". Since you're gonna change the skill tree many times during balancing the answer is yes. This is almost always true for data-driven gameplay features (ie, stats, skills...). It's almost always not true ("it's not worth it!") for things that are more or less set in stone, like game mechanics, combat, AI, and I've seen many developers getting themselves into an endless loop of refactoring, because you can obviously always make future changes easier by changing your design to be more generic/plugin-driven/offloading more data or logic into external files."

I think this is true and in some cases can prevent roguelikes from ever getting completed. Since none of us get paid to work on our pet projects, the temptation is to never set deadlines or abide by them. The desire to make the code "perfect" can make us spent all of our time making the code more generic to the point we're creating a game engine more that game itself. While this can sometimes be successful (ToME being the most obvious example), for 95% of us it doesn't buy us much.

If I spend 10 hours refactoring the AI to move it to external files, and then spend only 5 hours tweaking it over the next year, the change was obviously a loss. Even if I save some time, that needs to be balanced by the fact that the code is more complicated. As opposed to a function you can debug, a problem can be in the file parser, the external file itself, the code implementing the behavior expressed in the file, etc.

I have a few suggestions for other developers based on my experiences with magecrawl that so far have mitigated this issue for me (beyond my general pragmatic attitude).

Set deadlines, preferably short ones - When you want to finish your iteration in three months, spending a month and a half on something like swig'ing libtcod or converting libtcod's build system to cmake, makes you at least think about the trade off you are making.
Use bug tracking software - I love fogbugz myself, but the one built into google code or even bugzilla is better than nothing. When you find something you'd like to refactor or make more generic that would take longer than 15 minutes, go add an entry for this or a later iteration and get back to what you were originally working on.
Things that change often or by users should live in external configuration files, things that don't shouldn't - How often are you planning on changing your physics system? Even if you think this'd more more often than once, leave it hard coded for now. After the third time you mess with it, then go make it generic. By the time that third time happens, you'll probably have a better view on what to pull into data files anyway.
You can ignore any of these rules if you want to - beyond the fact that I'm just a random blogger on the internet, you are writing your game. While I think getting a working game done early is the best way to do things, realize you are doing it for enjoyment. If spending a year writing a engine that can make toast, run a neural net AI, or show pong on the screen, all with just changing configuration files sounds fun, go get coding.

One final node, I love comments on my blog. They are the breakfast of champions. Please feel free to leave them, they make things more interesting around here.

When making a type of change in your game is tedious, first fix things so that it isn't anymore

2010-07-25T16:01:00.000-07:00

So part of my balancing work involved buffing the player's abilities when it makes sense. One way to do this is to add new skills on the skill tree. However, the system I had in place for read/displaying the skill tree made me hesitant to do so, as even a simple change was a lot of work.

The previous system involved a text file with a grid of ascii characters laying out the exact location for each node, along with a list of positions below to match each one up with the associated skill. If I wanted to add more nodes, I'd have to manually place it, then calculate the offset and write it below. If I needed to make the grid bigger, I'd have to recalculate the offset of every node for that tree. It pretty much never should have gotten submitted in that state, but it was "good enough" for the simple trees I had implemented. The horror can be found here for those who are morbidly curious.

I noticed that all my nodes were in a grid, so I converted each text file into an xml file describing the skill tree. One example can be found here. I then wrote the xml reader and which would generate from the stored information the grid of characters to display on the screen. Overall it took about three hours to write, test, and submit.

In less time, I probably could have made my balancing changes and "got out" without making things better, but I would have been more likely to not add new skills in the future. Now adding a new skill is as easy as copy pasting an xml node and changing a few lines of text.

"Backgrounds" - The compromise of class selection and skill tree

2010-07-24T13:42:00.000-07:00

One of the unwritten design guides I've followed in magecrawl has been to not ask the player for choices they can't answer before the game starts. The first time I launch a game and am ambushed by something like this (care of Crawl Stone Soup):

I get overwhelmed with choices. What the difference between fighers and gladiators? What is the difference fire/ice/air/earth elementalists? These choices are ones that are difficult to make before playing (multiple) times.

The reason this came up during my initial balancing effort is that I realized balancing some options were difficult. For example, how much should the heavy armor skill be? I didn't want to start the player with equipment they couldn't use, so by default they'd have to scavenge for at least part of a set before taking the option would make sense. It'd need to be powerful enough that it'd be worth going to all that trouble, but not so broken as that'd be the only logical choice.

Letting the player choose to use armor/heavy armor before the game makes some sense, as I could start them with a set of said armor at the beginning of the game. I've decided to try to take some of the nice features of crawl's system and pair them down to something more reasonable:

Opinions? These starting backgrounds would provide the initial equipment and preselect some skills in the skill tree. However, there's nothing to prevent a Templar from selecting skills from a tree and become a ranged attacker, beyond the penalty from using heavy armor.

Current plans on dealing with game balance, with the first step being spelling it correctly...

2010-07-23T17:35:00.000-07:00

(Potential bloggers out there, don't write new entries when you are tired or else you might blast everyone's RSS reader with blatant misspellings like my last post)

So as I mentioned, balancing roguelikes is hard since doing so involves balancing multiple variables (with a significant amount of randomness thrown in). In an effort to motivate myself into finishing this work, I'm writing up a quick post on my decisions and strategy.

The first variable I focused on was damage output. I decided on a "base" damage an average attack should do, 10d3. For those not initiated in the "d" notation, 10d3 refers to rolling 10 dice with three sides, and summing them all up. 10d3 produces a range of 10-30, with 20 being the center average.

I chose d3s since they produce a nice range with some variability but don't have extreme variability. 5d6, for example, produces a range of 6-30, which is somewhat close to 10d3's range. However the possible "burst" of a good roll means five times the low roll or twice the average for 5d6, compared to three times the low roll or 1.5 times the average in 10d3.

Once I had the damage set, I needed to guess how many hit points monsters and players should have. I started with a guess that the average combat should last five to six rounds, which with twenty points being the average round means 100-120 hit points. For the player, I split these up in health, stamina, and bonuses from the average set of equipment I'd guess one would have.

The next variable is the rate of growth as the game progresses. Magecrawl doesn't have "levels" per say, but I assign an internal level to monsters and items. Each "level" of monster and equipment is currently scheduled to increase in damage and/or stamina by about 25%. This doesn't exactly work, I realized as I wrote the previous paragraph, since the player receives a majority of their hp from their initial stamina and health. Increasing damage monsters do by 50% while increases the stamina bonus of equipment by 50% doesn't even out. Still more to hammer out apparently...

Now that I have some guesses of numbers, I coded them in and forced the map generator to produce only a single type of monster. I'm planning on playing a good number of games, tweaking the numbers so that I can "win" a decent percentage of the time but not always. Once I have that single pairing balanced, I'll continue with others until I have a good feel on the numbers that are fun....

The trouble with game balencing is that it is hard....seriously

2010-07-20T16:11:00.000-07:00

So part of the long delay between this and the last post was a (hopefully?) well deserved break after a mammoth week of coding. However, part of it is related to my lack of progress in balancing the new monster/weapon/quality types. Trying to keep individual fights interesting while keeping ambushes from turning into two turn player-deaths and making it scale after (for now) 5 levels is hard. Like harder than writing the code that allowed it.

Part of the problem is I want to get rid of the issue I call "rounding-error bonuses". For example, let's say that having a quality weapon improves the damage by 15%. If your sword base damage is 1d4, then 15% is less than 1 point of damage. It'd have effectively no effect. One could solve this by increasing all the numbers by a factor, say 10, then the sword base damage would be 10d4 (10-40) and 15% is on average 3-4 additional damage. Getting these numbers correct, along with making them look reasonable isn't going so well. It seems weird to have the starting sword do 10d3 damage and average swings totaling 18 or more (maybe that is my experience in d&d based roguelikes and games talking).

Does anyone have a good system or set of tools for figuring this out? Bonus points if it has been proven in a shipping game or one at least farther along than magecrawl...

7DOMC - Day 7 - Monsters and thoughts on this week

2010-07-10T20:58:00.000-07:00

With my commit here I'm done with my XML generation changes this iteration. Monsters now have different names that are level dependent, with base stats and some stats that go up each level. The "trait" system has been booted to iteration 10 due to my exhaustion in this area of magecrawl. I need to create some content for items still, item levels for each armor/weapon from 1-6 or so, but otherwise I have the base material for a sane difficulty curve.

So, if you've read this blog any this week, you probably can tell that I've been busy. With my wonderful wife coming home tomorrow and family in town next weekend, it'll probably be a few weeks before I implement anything major.

Looking back on this week, I think the fact that I announced my intentions and wrote about them every day was useful. There were days that I didn't want to program, I would have rather played TF2 or Borderlands all night. However, the idea of skipping a day's post or admitting I didn't get anything accomplished pushed me to do some programming. Once I overcame the initial hump of launching Visual Studio, I generally started to enjoy my work.

In some regards I got less done that I expected, but I think that was due to me vastly underestimating how much work some of my tasks would take. Item generation based on levels took three or four times longer that I would have initially assumed. I think it would have taken even longer if I had to break it up over a week or two's evenings.

I have 26 items left targeted for this iteration. With the possible exception to my "field" idea for improving monster AI, each of them should involve significantly less work that either the item or monster changes this week. They should be "bite sized" enough to tackle one or two after work some night.

7DOMC - Day 6 - I thought I was done with items, but I made them better.

2010-07-09T23:27:00.000-07:00

So on day three I said I was done with the item rewrite. While this was a true statement, I realized today that there was one way I could improve items even more. The current system had each material list the base stats for a weapon/armor made of it. Something roughly:

Wood Club - 3d3 CTCost=1.0
Iron Sword - 4d6 CTCost=1.25
Cloth Armor - +5 stamina

The issues is that I had to list out each statistic for each material. If I know that say leather is 20% more stamina than cloth (the base type), I'd need to calculate that and put both values into the XML. If I decided to increase the base later, I'd need to update all the values again.

To fix this, I now have materials list a percentage or linear amount better they are than base. For example, Wood adds 1d3 damage and leather adds 20% more stamina than base. If I update the base values, the change will propagate to all armors/weapons.

C# - The dangers of int.Parse() on non-english systems

2010-07-09T21:44:00.000-07:00

I ran into this issue in a similar for way back in January here, but I stumbled upon in again today and I figured another post wouldn't be a bad idea.

This simple function

double ParseString(string s)
{
     return double.Parse(s);
}

is a timebomb waiting for one of your fans or customers to run into if s comes from a a source that isn't translated into the specific language. For my C/C++ fans, int.Parse() is similar to atoi() with a twist we're about to get to.

My part of the world uses a period to separate the whole from the fractional part of a number, "10.0", other parts of the world uses a comma, "10,0". C# will helpfully use the latter on systems who's language is set to be one that uses this system. This can wreck you, if for example, the string comes from xml data files that you don't want to change for each language.

There are two solutions. The simplest is to rewrite the function as follows:

double ParseString(string s)
{
     return double.Parse(s, CultureInfo.InvariantCulture);
}

That will use the "standard" english system of period for decimal seperate.

The second is one that works if you are about to do some operation that is going to call Parse a large number of times (e.g. Save/Load).

double ParseString(string s)
{
     // Save off previous culture and switch to invariant for serialization.
     CultureInfo previousCulture = Thread.CurrentThread.CurrentCulture;
     Thread.CurrentThread.CurrentCulture = CultureInfo.InvariantCulture;

     double result = double.Parse(s, CultureInfo.InvariantCulture);

     Thread.CurrentThread.CurrentCulture = previousCulture;

     return result;
}

Just be careful that if you expect your code inside the culture setting blocks to throw an exception that you plan to survive from, to rewrite this to use finally so that it always happens.

Now I have to go check every Parse() and fix up the ones that don't happen inside a save/load call...

7DOMC - Day 5 - Monsters AI changes wrapping up

2010-07-08T21:36:00.000-07:00

So, all the great AI work that I did a few iterations back can be distilled into this chunk of code now:

switch(typeName)
            {
                case "Bruiser":
                    tactics.Add(new DoubleSwingTactic());
                    tactics.Add(new DefaultTactic());
                    break;
                case "Healer":
                    tactics.Add(new UseFirstAidTactic());
                    tactics.Add(new MoveToWoundedAllyTactic());
                    tactics.Add(new DefaultTactic());
                    break;
                case "Ranged":
                    tactics.Add(new KeepAwayFromMeleeRangeIfAbleTactic());
                    tactics.Add(new UseSlingStoneTactic());
                    tactics.Add(new KeepAwayFromPlayerIfAbleTactic());
                    tactics.Add(new PossiblyRunFromPlayerTactic());
                    tactics.Add(new WaitTactic());
                    break;
                case "Sprinter":
                    tactics.Add(new RushTactic());
                    tactics.Add(new DefaultTactic());
                    break;
                default:
                    tactics.Add(new DefaultTactic());
                    break;
            }

I obviously plan on pulling this out into an XML list or something similar, and add more intelligent "tactics" so I can make the AI even smarter. One idea I had would have slingers who don't have a line of sight for a shot to move to one more likely. Another would have healers find bruisers and stay togeater, kinda like heavies and medics in TF2.

Now that I have a "flat" monster hierarchy, I need to write generators similar to the ones I wrote for items that'll create level dependent monsters.

7DOMC - Day 4 - Planning and Monsters

2010-07-07T17:56:00.000-07:00

So, after the craziness of the last two days, today is a bit more subdued. Part of that is a bit of burnout and part of it is busyness at work.

Even with the work {I've/I'm going to} accomplish, my chosen tasks for iteration 9 were a bit much. I pushed back 12 minor features to another iteration, giving me 28 total. For those doing math, that doesn't exactly add up to previous posts, which is due to me splitting a few tasks up into smaller bites.

Speaking on smaller bites, I'm working on refactoring monsters completely as well. I want them to be more attribute based, like skills and items, and have more flexible behavior. Since they touch a smaller portion of the code base, I'm doing my refactoring in smaller bit sized pieces.

Update -
So I'm not done yet, but here's the jist of it.

There is a set of tactics, which are discrete single actions that could or could not be preformed. Each tactics can be asked if it could apply now and ask to do it. Then a loop like this runs:

            m_tactics.ForEach(x => x.NewTurn(this));

            foreach (IMonsterTactic tactic in m_tactics)
            {
                if (tactic.CouldUseTactic(engine, this))
                {
                    if (tactic.UseTactic(engine, this))
                        return;
                }
            }

Each monster would have a set of possible tactics, for example, my healer AI can be stated as: UseFirstAidTactic, MoveToWoundedAllyTactic, DefaultActionTactic.

Each tactic setups the required attributes on the Attributes dictionary of the monster, which are serialized, so things are remembered past save/load like the cooldown on the first aid ability.

The cute thing about this is once i code up a great new behavior, I can slip it in the monster behavior list and it'll start acting that way. Once I'm "done", I'm going to be pulling the list of behaviors a given monster has out to XML.

7DOMC - Day 3 - The item rewrite is done...finally.

2010-07-06T17:16:00.000-07:00

So the patch I submitted was six thousand lines long, and took a grueling day of coding yesterday and half a day today cleaning up loose ends, but it's done. Much of the work involved moving a hierarchy of classes that defined weapon, armor, and consumable types into a flatter set of classes that allowed more dynamic changes.

A quick overview of the way I generate items follows:

For armor/weapons:
We start with an expected item "level", determining how "good" the item should be. We first calculate a quality grade, which falls from -2 to +4 on a normal distribution. We then determine how many "levels" we have left to choose the material. Each material, for example wood, iron, or leather, states what items can be made of it and what their properties are. Some materials have higher level modifiers, so a bronze would be lower level than say cold-forged iron. The material determines the base damage/speed/protection of the item, while the quality increases or decreases it by percentages.

For potions/scrolls/wands.

A slightly different approach is taken. An effect is first determined, using the requested level item as a range to select from. Wands cut the level in half, since they allow the effect to be produced multiple times. For any left over levels we increase either the caster level of the effect (for potions/scrolls) or the number of charges in wands.

I still need to implement the bulk of the content, for example material types for each weapon varying over the ranges, and a ton of playtesting to find bugs and determine values for each material/quality. However, the coding for this headlining feature is done. :)

7DOMC - Day 2 - The great item rewrite

2010-07-05T10:39:00.000-07:00

My first task today has been completed, which is moving all the skills to use the new attribute based system detailed here.

I looked at doing the same with items, when I realized that I'm going to have to rewrite pretty much my entire item hierarchy to do things right. I ripped out (with a backup copy for reference) all the item, armor, and weapon classes from the game engine, and commented out or "throw new System.NotImplementedException()"'ed all the code using them. Now I can start again from scratch and when the diffs show no commented out code, I'll be back where I started.

I very rarely try a rip out and rewrite. In general, I find a set of small incremental changes work best. However, the shear size of the item hierarchy was daunting to say the least. We'll see how this goes, I'll update later.

Update 1 (10 hours later)

So I have the weapon system up again. I've got generated weapons of various qualities and materials. The weapons damage is base speed comes from the material, with the quality affecting things as well. Descriptions are built up from the various parts, along with the names. Save/load works again for weapons. Much of the work was creating a brand new hierarchy for weapons, and the generator for materials and quality.

I'm hoping to get armor up quickly now that I have this base. Then I need to rework consumables, such as potions/scrolls/wands.

Update 2 (1 hour later)
Armor works, with quality, materials and the like. Now onto consumables.

Update 3 (1 1/2 hours later)
Obviously things are taking longer than I'd expect. I'm almost all the way through consumables but I'll have to wait for tomorrow to finish up and submit.

7DOMC - Day 1 Status

2010-07-04T19:33:00.000-07:00

I'm winding down for the night, and I'm pretty happy what I accomplished today. Here's what I accomplished today:

Magecrawl for Linux - This single task involved hours of work. rpath's still leave a bad taste in my mouth.
14 open tasks - I went from around 51 open items to 37. Some of these work items were tiny, while others involve entire features, so you can't say that I'm 27% complete however.
One of those open tasks required me bringing some sanity to how MagicEffectsEngine::DoEffect outputted text to the log. It look awhile, but now looking at that file no longer makes me wince.

However, other that the Linux task, I didn't touch any of my head lining features.

There is still much to be done this iteration (and this week).

Will the penguin in the room please stand up...

2010-07-04T11:27:00.000-07:00

Magecrawl now works on Linux again. You'll need a new copy of mono (one that isn't released yet but will be before my next release), but it works!

For those who care about the bad things I had to do to make this work, read on...

So, the major issues were causing problems was the libtcod-net-unmanaged library was not working as expecting.

The first issues was both mac and linux wanted to create a library called libtcod-net-unmanaged.so. I modified the make files to create to new files and used mono's dllmap to point the right platform to the right binary.

Once I fixed that, I was getting missing symbol errors. I had forgotten that libtcod.so doesn't have the C++ symbols under Linux. I linked against libtcodxx.so, copied that in, and fixed that.

The final issue, which took three of four hours to solve, invoked this bug in cmake. I had to use an internal "don't use this, it could break on new versions" macro to work around it. The code in question is:

IF(UNIX)
     SET_TARGET_PROPERTIES(${SWIG_MODULE_${CSHARP_LIB_NAME}_REAL_NAME} PROPERTIES LINK_FLAGS "-Wl,-rpath,.")
ENDIF()

with SWIG_MODULE_${NAME}_REAL_NAME being the forbidden fruit.

7DOMC - Seven days of magecrawl coding

2010-07-03T21:27:00.000-07:00

As I mentioned in my previous post, I have a huge list of things I'd like to accomplish in magecrawl in the short term. It just happens to be such that my wonderful wife is going to be visiting friends out of state until next Sunday. Combine this with a Monday/Tuesday holiday off work, and I have a significant amount of free time this week.

My hope is to stay productive (not just play Eve online and TF2) for most of the upcoming week. We'll see how much I get accomplished. I'll be posting updates as the week progresses.

"Iteration", I don't think that means what I think it means...

2010-07-02T22:40:00.000-07:00

So I have some time next week to work on magecrawl, and so I'm looking at my task list and realizing I currently have a ton of things targeted for iteration 9. Ignore the bug fixing and corner cases issues, I have these high level goals currently:

Create level dependent items and monsters
Refactor how skills and items are handled to combine with new traits for monsters
More effect work, including debuffs specific to various schools attack spells.
"Field" effect to model sound/smell to make monsters seem more realistic.

In addition to this, I currently have 51 open issues targeted to iteration 9. Some of these issues are minor, but some include creating new classes of items, major new spell types, and other significant chunks of work.

I'll talk about my short term programming goals later this weekend, but the short answer is unless I seriously knock a lot of this work out soon, I'm going to have to punt on stuff to an iteration10 or have a bloated schedule.

A generic system for implementing skills, traits, and item bonuses...

2010-06-21T20:02:00.000-07:00

I know the title is a mouthful, but if beyond it is an idea I'm excited about. Like most ideas, it came to me when I was doing something other than programming.

This iteration I'm planning on implementing varying difficulty monsters and hopefully items of varying strengths. In my previous post, I suggested using a "trait" system to implement some of the monster characteristics. For example, one wolf might be "fast"-er or "strong"-er than another, trading that off against some additional base attributes. In my head I hoped to sneak in items with enchantments; a sword that could make you tougher or a staff that made you case spells better.

It came to me that both of these use cases are very similar to the skill tree attributes I implemented last iteration. Those skills could increase base stats or allow new skills. As a programmer, when I hear of three different implementations of an idea, I get an itch to make a generic framework or factor out the pattern or something.

The crux of the idea is that all of these ideas can be implemented as a system of tags and values. For example, a skill that increases the characters base hitpoints by 5 could be:

m_player["HPBonus"] = 5;

Then to calculate the number of hitpoints in this simple example one can do something like:

// Player
int GetSkillTags(string tagName)
{
    int total = 0;
    foreach(ISkill s in Skills)
    {
         if(s.attributes.Contains(tagName))
             total += s.attributes[tagName];
    }

    foreach(IItem i in Equipment)
    {
         if(i.attributes.Contains(tagName))
             total += s.attributes[tagName];
    }
    return total;
}

// Monster
int GetSkillTags(string tagName)
{
    int total = 0;
    foreach(Dictionary<string, int> d in Traits)
    {
         if(d.Contains(tagName))
             total += d[tagName];
    }
    return total;
}

Once I implement a given skill or trait checking in one section of the game engine using this API, creating a new skill, item attribute, or monster trait to do the same thing is trivial. Also, since checking if a dictionary contains a key is fast, it should be efficient as well.

Thoughts?

MEF is now cross platform friendly, kinda

2010-06-20T20:41:00.000-07:00

So in February I noted some attempts at using MEF and the disappointment that it was Windows only at the time. MEF in short is a way to break up your C# application into smaller pieces that are loosely connected.

Since multiple of the tasks I have for iteration 9 involve refactoring, I figured I'd take a look at MEF again and see if it is in better shape. The short answer answer is that it works with mono, but only in their development branch. A kind fellow in the mono IRC channel pointed me to a copy he built of System.ComponentModel.Composition.dll that I could use. It works under Windows, Mac, and Linux.

In the next release of Mono it seems likely that this will be built into the .NET 4 client profile, but packaging a single assembly along with your application seems to be an easy solution for now.

Once I break up magecrawl into smaller components, I'm planning on making another post describing MEF and showing how I used it.

Iteration 9 - "Levels" and polish

2010-06-19T17:24:00.000-07:00

So, I haven't had the time I wanted to work on magecrawl this week, but the ideas keep coming. I have over 50 major/minor/bug fixes I wish I could get into this iteration. Before an iteration, I try to come up with a "theme" tying together what I hope to accomplish in the next few months. This iteration (9), the theme is "Levels and polish". It also may be the last iteration before I move onto the next stage of my development plan.

The "levels" in the theme refer to varying levels of difficulty in challenges, not different floors connected by stairs (which I already have). For example, the wolf that attacks you at the very beginning of the game should be different than the wolf pack that hounds you a few levels later when you have better equipment and skills. The quality of treasure should also vary based on depth.

My current idea is to create an engine that creates these monsters and items on the fly. For example, asking for a level 3 monster could create a fast (+1 lv, 25% faster), strong (+1 lv 25% dmg) base kobold (base creature). Or it could create a experience goblin (+2 stat levels). A combination of traits (such as fast, strong, special abilities) and stat levels (more hp, etc). A similar system would exist for items, so creating a level 5 sword could return a masterwork wooden sword or a crude iron sword. Each quality grade and material would contribute to the effective level of the item, along with any enchantments.

I think this system should help me balance magecrawl's difficult curve. Manually creating monster and item stats based on paper calculations is difficult and time consuming.

In addition to "levels", I have a huge number of polish issues that I'd like to implement. They range from the status effect ideas I listed here to internal refactoring to improving monster AI.

As I mentioned, this might be the last "iteration" of magecrawl. I think I laid this out on some other post, but finding it escaped me. The idea of iterations are to fill out functionality needed in the game engine and GUI needed for a "real" game. After I feel like I have enough functionality, I'm planning on moving to "slices". Slice would be a portion of the full planned game, from top to bottom. For example, the first slice could be implementing the entire fire skill tree and all its spells, and flushing out sections of the dungeon. The game itself would be a full (albeit shallow) game. After releasing that, I'd take another slice of say the water tree and more dungeon sections.

Well I should get off to coding...

Status Effects 2.0

2010-06-12T09:23:00.000-07:00

The initial implementation of status effects, the one you may have seen in the first three tech demos of magecrawl, was almost an exact reimplementation of the model used in crawl. Effects when cast have a length (in turns or ticks or whatever) at which time they disappear. Some effects are positive, some are negative. If you have a positive effect (say haste) that you want to have on you permanently, you need to recast it was it expires. Some games automate this step, but in the end it is the same model.

While simple and easy, I don't really like this model for magecrawl. Mages in books and legend sometimes were wrapped in layers of magical protection, and the idea that you need to stop walking every five minutes to recast all your buffs seems silly. I'm stealing a page from dragon age, and separating effects into two orthogonal categories: length and type.

Sustained effects (long term) are ones that persist until canceled, however have a continuing cost. My current implementation reduces the player's maximum MP by an amount for each effect that persists. This provides a nice trade off; keep no effects up and have access to your entire mana pool, keep some up and have only part, or keep a bunch up and be able to maybe only cast one spell.

Temporary effects are effects that use the traditional effect model of a deadline time and no additional cost while in effect. Unlike sustained effects, where having a sustained negative effect doesn't make sense, temporary effects can be positive or negative in nature. Positive effects that are too powerful or come from items could be temporary.

Another status effect idea I had, which I haven't implemented yet, are school specific debufs for common attack spells. An simple example would be the school of fire. Fire attack spells could have a chance to apply a "burning" negative status effect upon targets. Some spells (like sticky flames) might have a higher chance to apply effects than others. In the case of burning, it would do damage over time to the target. If attacked by any water or ice damage damage, the effect would end early.

Some effects I have in mind would reduce damage taken by some schools and increase others (e.g. being frozen reduces fire damage but a good earth spell would shatter the target nicely).

Effects might be a trait added on by skills in the skill tree, so the initiates fireblast might do damage but not be powerful enough to set things on fire. It also brings up the possibility of branches in the skill tree, where some could specialize in damage over time or status effects while others specialize in raw power.

I think status effects will be on the areas I focus on for this iteration. I think it can be used to bring out a lot of flavor and interesting choices in magecrawl.

What I've been up to the last few weeks...

2010-06-09T18:53:00.000-07:00

In the age of please rob me and other such sites that make it easy to find people's home location, stating online that I was going to take a 10 day trip out of the country didn't seem like a good idea. Hence the "things are going to be crazy" excuse. My trip to Russia was wonderful if your are curious.

Given the 12 hour flight both ways, I did get some hacking on magecrawl done. I refactored and redesigned how status effects work. I'll get around to writing it up as a long post hopefully this week.

Now that I am back, and mostly recovered from jet lag, more forward progress on magecrawl seems likely. I have an idea list a mile long I need to enter into fogbugz, and I need to come up with a high level plan of what I'm going to accomplish this iteration.

Magecrawl Tech Demo III release for Windows/Mac

2010-05-25T19:55:00.000-07:00

Magecrawl Tech Demo III is available for download. The difficulty is a bit harder that I would have liked, but should be playable. You can find it for Windows and Mac here.

The new features compared to the last release include:

Skill Tree - This is the headlining feature of this release.
Mac Support!
Preferences for keyboard mappings with presets for arrow/vim/numberpad.
Overlays for multiple targetted effects (Spells like fireball, lightning bolt, and cone of sparks).
Welcome Screen
Plenty of bug fixes and crash fixes.

To play magecrawl, a few dependencies need to be installed.

For Windows - the .NET 3.5 runtime is all that is needed.
For Mac - Install mono, SDL, and libpng

Since libtcod uses .dylibs for mac, the dependent frameworks need to be installed, not next to the program. I think there is a way around this, but I haven't had time to look into it.
On some mac laptops the default resolution will place magecrawl overlapping the dock. Two workarounds for this include setting the dock to auto-hide or uncommenting the line in Preferences.xml "True" so that magecrawl will run full screen.
To run open a terminal to the folder you unziped, and run "mono MageCrawl.exe"

If magecrawl happens to crash, a file called DebuggingLog.txt should be created in the magecrawl directory. Please note that this release is using an SVN version of libtcod, so be forgiving of any issues that crop up. Please send that file along with any description of the issue to chris dot hamons at gmail dot com.

I'm sure there are some Linux fans out there that are wondering why Linux got left in cold. The short answer is that I ran into a last minute issue preventing the new SWIG'ed libtcod from working on my test vmware. As I won't get much time to work on it for the next two weeks, it was either delay the entire release or skip Linux.

I'd love to hear feedback on Magecrawl; the good, the bad, and the flames about using .NET and how it made your goldfish sick. Send them to: chris dot hamons at gmail dot com

Things are going to be be pretty crazy personally for the next two weeks, so if you comment on a post or send me feedback/bug reports, please forgive the long reply times. Once I get past the next two weeks, I should be back on starting for iteration 9.

Balancing combat is hard, Let's go shopping!

2010-05-21T21:05:00.000-07:00

It is amazing how difficult it is to balance the numbers that underlay combat. I've been messing them for a few hours now, and I have the game currently somewhere between Crawl and the "Nightmare" difficulty in doom. I can't get past the first level most of the time, so it needs some toning down obviously. A few thoughts:

Splitting HP into a regenerating and non-regenerating part is working great. For me, it makes the initial part of combat not-painful, as I don't feel like I'm burning non-replaceable resources (if hp didn't regenerate). As combat continues, it gives me a reason to finish quickly as soon as I get near the end of my stamina bar. If I let it continue past that, I start taking damage that won't regenerate easily.
Right now, allowing the player to rest after combat along with tough monsters makes the game feel like you're the little guy against the big army. You have to slink away after taking a guy or two down and rest before more find you. I've caught myself finding corners and cracks in the wall to press myself against before I hit '/' to rest to decrease the chance of a wondering monsters from finding me mid-heal.
In the next iteration, I have a rough idea how to model things like sound, smell, and visual changes due to battle. That will make monsters even more likely to stumble upon the player while he's resting. I'll have to tie that along with a system to keep some enemies grouped up, so groups don't turn into hide around a corner and pick one off at a time.
I've been tempted to go play a video game tonight instead of doing the work on my own, hence the title. For those who don't get the humor of the title, see here.

End of iteration 8 within sight....stay on target...

2010-05-20T21:38:00.000-07:00

I'm down to three bugs for this iteration, then testing and polish. I implemented the first pass of my ideas on health and damage, with now stamina and health instead of hp. The idea of a "shield" spell is a good one I think, but I want to wrap this iteration up.

For those curious, the three bugs I have left are:

"Armor should increase stamina, not evade/resists"

For now I'm going to remove the fact that armor gives evade/resist on damage. It's going to increase the amount of stamina you get, aka damage you can soak up. I'm doing this since evade is not what I want, it makes combat way too "bursty". Four rounds of missing followed by 2 hits and your dead.

"Make combat take longer per enemy"

Somewhat related to the first one, right now combat for a given monster takes on average 3 rounds. I'd like that to be closer to 6 rounds. Enough time that doing status effects, healing, and such make sense. This involves buffing the hp and mp numbers on both sides. I'm going to try to bring some sanity to the way that numbers are handed out now.

"Cone and blast need to handle things blocking exploding correctly"

This was just something I ran across and didn't like. Here's some awesome ascii art to show you what's up

. . . . . . . . . y

. . . @ . . # # #

. . . . . . . . x

If the player cast a fireball to x, y would be hit even though there's a wall between them. The current idea I have is for each point in the blast radius to make a line of sight check against the focus point.

Skill Tree Complete for Iteration 8

2010-05-18T18:41:00.000-07:00

So the planned features for the new skill tree in iteration 8 are complete. Here's what it looks like

I now have 3 somewhat fleshed out trees (at least fleshed out for a tech demo) and one token tree. SP are earned for killing monsters, and spent in the tree. Dependency information and skill point costs will show up in red on cursor over if they can not be met.

I've determined that in the short term at least, I'm going to have magecrawl use a pure skill approach, with no "character levels". As players get SP, they can level up in both new spells and abilities to improve existing ones. Right now the skill tree is filled out just for showing that it works, but in the future I expect each tree to have 30+ nodes. If you want a glass cannon, you spend points just in the elemental trees and none in the martial trees. If you want a "mystic knight" you spend half your points or more in the martial tree, earning armor and improved stats, and cherry picking the light or elemental spells you need.

Balancing everything is going to be painful in the short term, but with SP being the cost skills, I hope it is manageable. Much play testing and feedback from early players will be needed.

FogBugz says I have about seven hours of work left right now.

Assuming that keeps somewhat on schedule, I should have a tech demo out by my new-self imposed deadline of middle of next week.

More Skill Tree Goodness

2010-05-12T17:30:00.000-07:00

The skill tree is starting to shape up. Here's what the current build looks like...

I've added dependency information (albeit in a kinda hacky file format), and a "tab bar" of different trees. Each tree is read from a different file, and can contain any number/configuration of different skills.

Here's the confirmation dialog I mentioned from last post...

The spellbook ('z') now takes its cue from the skills the player has taken, with a few skills that provide spells already created. I need to add skills that provide improvements in spells, ones that passively increase stats, and ones that allow the use of certain equipment.

Laptops on a plane, some things take longer than you'd expect...

2010-05-10T07:14:00.000-07:00

So last week I went home for a family member's college graduation and had the joy of bringing my new laptop along. Hacking on code for 3-4 hours makes plane trips seem faster and airport waits suck less. Here's whats new:

In skill tree can select/deselect nodes, which change color
Selecting new nodes on dialog exit will add them to a list the player has, which is persisted.
On next open of skill tree, previously selected nodes show up a new color and can not be removed
A dialog appears when you exit with new nodes, asking to confirm the changes
Initial work on dependency information, so you can require some skills for another

It was that second to last item that took the longest. The problem with nice generic framework code is that sometimes it is hard to add new things. In this case, it was one dialog bringing up another dialog which refused to be dismissed until a choice was made. On selection, it had to communication back to the original dialog the choice made. Make all that a generic dialog for any two button dialog, and that's what I implemented.

This isn't that hard if you have one of the sub-dialogs run a message pumping (draw, blit, read keystrokes) loop, but that is something I have vowed never to do again. It took 5 or 6 classes and a bit of thinking, but it works now.

Things to do until skills can be considered "good enough" for this release:

Finish up dependency information on skills
Make selected skills do something: add spells, increase stats, allow equipment, improve spells
Make skill tree take skill points to select nodes, reward these for level ups, so create exp for player

Skill Tree Initial Work

2010-05-04T06:55:00.000-07:00

So one of the primary goals for this iteration was a skill tree. I love games with an in depth set of skills to choose from. Whether strategy games, or RPGs, having a long tree to climb with choices and tradeoffs brings a richness that I enjoy.

I'm far from there yet, but here is what I have so far...

It's a "field" of nodes, read from a file. Each one is associated with a skill read from xml. It currently doesn't do anything yet, but the idea is that as the player levels, they will get skill points, to spend in the tree.

In the future, it will be a tree (or more accurately, a forest), with dependency information. Some nodes will give new abilities, other improve existing ones. There will different trees for each spell school, and most likely a tree for "martial" skills like weapons/armor/etc.

An idea I've been kicking around is making the cost of nodes dependent on the number of nodes you already have filled in on a given tree, and inversely dependent on the number of nodes filled in on the opposition tree. For example, every node you fill in on the fire tree makes other fire skills cheaper, but adding water nodes makes fire nodes more expensive. That way, we make dipping into opposing schools more difficult but not impossible.

I have a lot of work to go, but I'm excited about the concepts and what I have implemented so far. Any thoughts?

Magecrawl Title Screen

2010-05-02T19:31:00.000-07:00

So doing a welcome window this early is a bit of gold plating, but it was fun to knock out.

The idea is that the large text block contains snippets of stories in the game world, things like passages from books, letters, and travel tips. Fluff in general, but also trying to give you a feel for the world I'm trying to create.

The smaller text block to the lower left gives a sample listing of spells in a given school. The lower right text block is a short description of the spell school.

The title screen is a bit wall-of-texty, but a good first try. I'd like some awesome graphics or animations, or snippets of game play in the future, but that's something I can punt on until a 1.0 at least.

Magecrawl on Mac Part II (libtcod, SDL, and init code...)

2010-04-25T12:12:00.000-07:00

This is a bunch of technical details about getting libtcod working on the mac. You might just be interested in the announcement post.

As promised, this post is a breakdown of the work it took to make libtcod work natively on the mac. By "native", I am not knocking the wonderful work Michael De Rosa did for previous releases. I'm referring to ones produced auto-magically by the cmake system, no manual xcodeprojs, .dylibs and all.

The wonderful part of generated xcodeprojs is that they will stay in date as further changes are made. Nobody has to figure out what changes were made, and manually update things. This hopefully means that mac ports of the new version should come out same day or very soon after releases.

Enough about that...getting libtcod working on the mac involved two major sections of work.

Part I: Build system

Getting cmake to play nicely with the mac wasn't too painful. I had noted places in my CMakeLists.txt where apple variables were needed when I created them, so the first step was filling them all in. Unlike the windows builds, the mac build currently uses the framework versions of libsdl and libpng. I'm unsure if this will require users installing those frameworks before use.... I did this since I wanted .dylibs of libtcod. The only other issue that SWIG apparently doesn't ship arrays_csharp.i built in for the mac. I had to download it from svn and copy it into the right place.

Part II: Crashes on launch, init code, and mac

This is where the pain started. The sample programs crashes on launch, due to an objective c exception about preconditions not being met. After some digging, I found this. Apparently, SDL does some funny business to get initially properly on the mac. You need to include an object c file in your build and use a particular version of a main function.

What happens on the mac is when you include the SDL headers, it renames your main via macros to something else. The objective c file defines its own main statement, which does the correct initing and then calls SDL_main which calls your main.

This obviously doesn't work very well if your a C# program who doesn't have a main! I had a friend at work who know objective c well to bounce ideas off of, and then I ran into this. It's a simple objective c method I could call from C code before initing SDL that would handle the mac stuff for me. No more renaming main nonsense for me. It worked great.

Just one note, all of this doesn't apply if your use the "unix" style SDL libraries. Those you can use just normally, they don't need extra setup. However, I wanted a "real" mac port, dylibs and all. There is now code in libtcod that will fixup the mac specific stuff when you call console init. Hence, it works fine no matter the calling language.

I normally try not to get this implementation specific when writing posts, however I couldn't find all this info in one place. If somebody is trying to get an SDL based library working on the mac, particularly in C#, I hope this info finds you well...

Magecrawl on Mac Part I (Announcement)

2010-04-25T11:37:00.000-07:00

Success!

One libtcod had a working mac version, getting magecrawl working was trivial, thanks to the wonderful work by the mono team. Other than a bitness issue that was my own stupid mistake, all it took was dropping the native libtcod mac .dylib and. so, adding a single config file, and off it ran.

Getting libtcod to work on the mac was a bit more work, and a very technical breakdown of issues and solutions will follow in another post soon to come.

Now back to prototyping that skill tree viewer...

CMake support for mac osx

2010-04-22T07:03:00.000-07:00

So I said I was done screwing with libtcod for awhile, but my new laptop thinks otherwise. It is now obligatory to get magecrawl running on it. And so...

This morning I got samples_c to run under Mac OSX. There was a bunch of nonsense with sdl_main and such, but I got it working. Now I need to get the other tools working, clean up the patches, and then create libtcod-net for mac. Then I can get back to magecrawl.

Laptop l = new MacbookPro(13);

2010-04-19T15:03:00.000-07:00

I wanted to write a quick post from my new laptop! I just purchased a 13-inch macbook pro and so far its pretty awesome.

After I "move in" by copying all of my media and installing all the needed applications, my first task on it will be making a cmake native libtcod for OSX, so I can get libtcod-net working, so I can get Magecrawl running. :)

Introduction to magecrawl's architecture

2010-04-17T15:58:00.000-07:00

So magecrawl is broken up into three libraries and an executable that pulls everything togeather and provides "the game". Since I have a few minute between yard work excursions, it seemed like a good idea to write a quick introduction.

Utilities - This is the base library that the other three components depend upon. It provides a few common data structures that c# doesn't (Pair, Point), a few extension methods on basic types, and a Preferences infrastructure for reading config files. Mostly stuff that needs to go somewhere everyone depends upon.

GameEngine - This is the library that "runs" the game world. It provides an interface IGameEngine which other modules use to request data to display and input player actions. Right now, it handles everything not GUI related almost: level generation, save/load, monster AI, physics, etc. It provides interfaces like ISpell, IItem, ICharacter and such so the GUI doesn't have to depend on concrete implementation classes.

GameUI - This library handles displaying everything. From dialogs like inventory and spell listings, to the map and character info, there should be no other place that any drawing code goes (Exception, the title screen goes elsewhere).

Magecrawl - This is the executable that the user runs. It sets up the libtcod console and displays the "welcome window". After a game is started, it then creates a GameEngine instance and runs the game's main loop. There are multiple keyboard handlers, which switch off responsibility depending on the state of the game. They handle keyboard keystrokes, creating requests to the GUI to display various dialogs, and sending various action requests to the game engine.

One area I'd like to talk about is handling "psydo-asynchronous" events. Things like monsters using ranged attacks between player's turn. By default, after the player does an action that causes time to step forward, all the monsters to act before the player gets anther turn happen consecutively, without UI updates. This keeps the action going. However, seeing ranged attacks is really nice. They way we handle this is via a callback.

The main magecrawl event loop registers a few events delegates with the game engine, to be called when the player dies/wins or an event that needs to be drawn happens on a non-player turn. When the game engine runs across one of these, it calls this callback, which then draws the animation and return. It looks something like this.

Main Event Loop -> Handle Keystroke -> Game Engine Do Action - > Game Engine Pass Time -> Monsters Act -> Physics Engine Display Ranged Attack -> Main Event Loop Handle Animation.

After the animation is drawn, we can return back to the other monster's action, and back all the way to the handle keystroke and main event loop.

This is done so there is only one place we "pump messages", in terms of the draw/flush loop. We also don't have the game engine trying to either draw updates or call Magecrawl functions, causing a circular loop.

I am very happy with this design in general. The GameUI/GameEngine divide provides a strong UI/logic separation, and the Magecrawl executable is the only person running event loops. Previous attempts at writing magecrawl have floundered due to event loop or ui/logic problems.

I threw a bunch of ideas down in the space of a page of text, so I'm sure i glossed over a bunch of details. Let me know if there's parts that weren't clear.

System.Reboot(Magecrawl.Iteration8);

2010-04-16T06:45:00.000-07:00

So I don't have the link the last two months of posting to make it apparent that I haven't been working on magecrawl lately. I'm hoping that now I've finished 95% of those other jobs, with just a few maintenance tasks to complete closer to the next release. This iteration has lasted way too long already, so this morning I'm separating the goat features from the sheep ones.

The original goal for iteration 8 was "different level monsters, a skill tree for the player, and increasing difficulty". I've booted what I consider the non-essential tasks out of this iteration and this is what I come up with:

Since it has been so long since my last beta of magecrawl, I'll kick out one after I get all of this done.

I haven't mentioned this lately, but magecrawl is open source. Feel free to download the source to take a look at how things work if you'd like. If you'd like to hack on a feature, let me know, there is plenty to do still.

As you can see, a skill tree is in the queue for this release. I'm hoping to flesh out an idea what that is going to look like in a a future upcoming post.

Completed C# and Lua Swig Wrappers!

2010-04-15T06:30:00.000-07:00

It has been a busy couple days since my "I'll get the wrapper up here that night" post. A few more last minute issues, including a weird race condition with different .NET runtimes that I think I ironed out, held this up, but now it is ready.

C# Wrapper

Lua Wrapper

The C# wrapper is now powering magecrawl, which is a pretty significant codebase, so hopefully most of the issues there are ironed out. With Lua, the "hello world" demo works, but I don't know lua well enough to test it beyond that.

Please note, that the libtcod these use is the svn of the upcoming 1.5.x release, and is therefor unstable. The API might change, it might crash, it could steal your girlfriend and watch TV while you're at work, so report bugs you find so they can ironed out early.

Beyond that, I finished all the C# documentation for the new release, so when that comes out, C# will be a first class citizen. My todo list for libtcod is just about done now, so expect a new post in the next few days talking about scheduling magecrawl and "rebooting" this iteration.

libtcod -> swig -> magecrawl -> true

2010-04-10T13:34:00.000-07:00

Today I finally got magecrawl working with the SWIGed wrappers. It was a 2800 or so line diff, but much if that is how noisy diff can get when you change only one line in a file. Much of these changes can be traced to the printLine changes that are inbound for the newest libtcod.

Beyond tracking down some bugs in libtcod (joys of living in bleeding edge svn), the changes where very mechanical. Find and replace will get users of libtcod-net 90% of the way there. For theses pains, they will receive APIs previously unwrapped (height map), new APIs as soon as they are released (the new textbox module hopefully), and much faster turnaround for new releases.

I will get together a C# and a lua demo zip later this evening, so people can tests things out if they want.

The obligatory magecrawl screenshot

Quick status update...

2010-04-03T10:05:00.000-07:00

I just finished getting the libtcod c# swig demo working. There are some performance places I'd like to work on at some point, but it's very reasonable (160fps vs 200fps on initial screen).

I'm going to walk over the diff, and figure out which places of the API could use some renames or cleaning up. I know the print/printRect functions need some love, and the noise functions, but beyond that I think I'm in good shape.

Post that, I'll port magecrawl to use the new API. I'm hoping that turns out to be straightforward. I'm guesstimating 4 hours of work. After that, I'll know that things work great, and I'll post a second version of the wrapper for public testing.

swig'ed libtcod c# demo sucess...

2010-03-31T18:49:00.000-07:00

There still are multiple modules not working right ~~and a crash on exit in TCDODijkstra~~, but I got the demo in c# ported to the new API and working!

Between craziness at work and work planning a trip over the summer, my hacking time has been scare this week, but I feel like this is good progress.

Update: The TCODDijkstra crash appears to be a bug in libtcod itself, as I can reproduce it in the C++ demo. I've notified one of the maintainers.

Update^2: The crash was fixed in all of 15 minutes, nobody can say the libtcod maintainers aren't responsive.

Sometimes you have to use a bigger hammer...

2010-03-27T21:40:00.000-07:00

This evening I spent awhile trying to hammer the SWIG'ed c# wrapper into something usable and less ugly. I've fixed all the "known" issues with the wrapper not wrapping some modules or functionality. The reduction in ugliness is related to the C-style enum and data type names. Things such as:

TCOD_BKGND_NONE
TCOD_key_status_t
TCOD_NOISE_MAX_OCTAVES

While for C users there is nothing wrong with them, users of higher level languages expect identifiers with less capital letters and underscores. After spending an hour or two trying to do it "nicely", I finally settled with adding somewhere around 200 lines like:

%rename (NoiseMaxOctaves) TCOD_NOISE_MAX_OCTAVES;

While a few VIM macros made this less painful that first glace would suggest, it still took awhile. It isn't a very elegant solution it works.

Now that I can type the constants without wanting to cry, I'm working on converting the C# libtcod-net demo program to use the new API. It started with about 400 compiler errors and I still have 230 to go, so it will take a while. It also means converting magecrawl (and by extension all the users of libtcod-net) will take awhile.

libtcod and swig - The current plan...

2010-03-24T20:40:00.000-07:00

tbellin stepped up and figured out the swig documentation when it came to callbacks. He's tested in C# and apparently it works. I'm thrilled that somebody figured it out. :)

From reading the documentation, the given language needs "director" support for callbacks to work, so some languages like lua are out of luck for now (until SWIG adds more support) unfortuntly.

As I mentioned in the comments sections yesterday, here are my plans:

~~Get heightmap finished~~
~~Fix one issue with callbacks user data.~~
Port the libtcod-net demo application to the new libtcod wrapper for testing.
Port magecrawl to the new libtcod wrapper for more testing.
Release two "official" platforms

C# - If things work out, for the period of at least a release support both the new and old library. Strongly encourage people to move to the new wrapper.
LUA - While it'll have to not have support for callbacks (stupid swig director support), it's still "good enough".

Ask people who are interested in other languages/platforms to work with me to bring those languages up to a good enough level.

Wrapping up libtcod, swig, and cmake nonsense soon hopefully....

2010-03-23T16:55:00.000-07:00

While I've enjoyed the libtcod, swig, and cmake work, my interest is seriously starting to wind down. Here's a status update:

libtcod-java - See this mailing list post. Nobody has answered yet, and I have no clue how to get it working right now. This might have to be stowed.

libtcod-php - Waiting to hear back from person who wanted it to see if they wanted php4 or php5. cmake apparently only support php4 naively.

libtcod-ruby - Apparently there is some interest in this, but it isn't working for them. Will be trying to sort that out.

libtcod-cmake-osx - Working with somebody via e-mail (slowly) in order to try to get this working.

libtcod-csharp - Working with somebody via e-mail to sort out crashes and problems I'm not seeing.

Bit of libtcod swig isn't wrapping - Heightmap is down to four functions not being wrapped. BSP looks like a bit of a lost cause. The SWIG documentation on function pointers and callbacks is almost unreadable. The only way I can figure to wrap it is to remove the callback, and create functions that return lists of all the nodes in the BSP in the requested order.

libtcod-ruby...

2010-03-21T18:01:00.000-07:00

Well I have something done for ruby, but it isn't up the my normal standards (aka the demo isn't done). Here is what I have:

http://libtcod-net.googlecode.com/files/libtcod-ruby%20bits.zip

This is a built libtcod-ruby library, for Linux. I can't understand ruby well enough to get a hello world demo working, but require "libtcod-ruby" seems to work. If one of you ruby people want to get a demo working, I'll post it.

The reason that it's a Linux demo is because cmake seems to be utterly broken for finding ruby under Windows. After spending entirely too long messing with it, I gave up and built it under Linux. If someone want to try to get libtcod-ruby working under Windows, let me know and I'll point you to where I've given up.

Off to libtcod-php and libtcod-java, then fixing the known issues and then maybe I can go back to Magecrawl...

libtcod in LUA, any more requests?

2010-03-17T21:06:00.000-07:00

I now have the same demo from yesterday in LUA for download.

Download

Here are the list of output languages SWIG can target:

Allegro CL
C#
CFFI
CLISP
Chicken
Guile
Java
~~Lua~~
Modula-3
Mzscheme
OCAML
Octave
Perl
PHP
~~Python~~
R
Ruby
Tcl
UFFI

If anyone is interested in libtcod wrapped in any of the above languages, speak up and I'll see what I can do.

Otherwise, I'm going to work on fixing up the known issues with these SWIG wrappers so I can hand some/all of it off to somebody else and go back to work on Magecrawl.

Prototype libtcod + swig wrappers (python & C#)...

2010-03-16T22:18:00.000-07:00

So I finished up the 95% of wrapping libtcod via swig today. The major outstanding areas not done are heightmap and bsp. Heightmap just because it passes a lot of arrays around, and bsp since it uses callbacks. I'm still not sure how I'm going to handle both of these.

Since they were easy to push out (and it's midnight my time right now), I'm just doing python and c#. I hope to get java and/or lua done tomorrow.

Python Demo

C# Demo

Remember, these are demos. They could eat your leftovers in the fridge or cause your program to explode, so be careful. And if things do explode or don't work, let me know. These demos are at the "it compiles, ship it" quality level.

Still more non-magecrawl work...

2010-03-16T07:03:00.000-07:00

I keep promising myself that I'll get back to magecrawl soon, but right now this libtcod/SWIG work is keeping me busy. I've almost gotten the Console, Colors, and System classes wrapped. I find that googling for what I want to do is almost strictly better than looking it up in the documentation.

I'm figuring that once I get the hang of all the operation types I need to do in the conversion, that adding additional modules to the SWIG build will be easy. We'll see how well that assumption holds...

All your libtcod wrapper are belong to us...

2010-03-13T11:43:00.000-08:00

(Apologies in advance for the title, but it was too good to pass-up).

The primary reason for my cmake work all of this/last week was so the build could get out of my way and I could experiment on some idea for wrapping libtcod. While libtcod-net works, and is good enough for writing magecrawl, I've seen multiple people going through the work of wrapping libtcod for each language they are interested in (python, c#, D, lisp, etc). Other people have been interested in using libtcod with java or other languages, but lack the time or skill to create their own wrapper. I'm also lazy, and if i can automate or reduce my workload, I'm all about it.

SWIG is a program that generates the "glue" layer so higher level languages can call C/C++, doing most of the work for you. It's a powerful program, with terrible documentation. At work, I've used it enough to feel comfortable trying it on libtcod.

After a morning of work, I have a proof of concept.

python:
import libtcod

libtcod.TCODConsole.initRoot(80, 50, "Test - python", False, libtcod.TCOD_RENDERER_SDL)
root = libtcod.TCODConsole.root.fget()

while not libtcod.TCODConsole.isWindowClosed():
    root.putChar(10, 10, 64);
    root.printLeft(3, 3, libtcod.TCOD_BKGND_SET, "Hello World");
    root.flush()
    root.checkForKeypress()

c#:

using libtcod;

namespace TestApp
{
    class Program
    {
        static void Main(string[] args)
        {
            TCODConsole.initRoot(80, 50, "Test - C#", false, TCOD_renderer_t.TCOD_RENDERER_SDL);
            TCODConsole.root.setForegroundColor(TCODColor.white);
            while (!TCODConsole.isWindowClosed())
            {
                TCODConsole.root.printLeft(3, 3, TCOD_bkgnd_flag_t.TCOD_BKGND_SET, "Hello World");
                TCODConsole.root.putCharEx(10, 10, '@', TCODColor.white, TCODColor.black);
                TCODConsole.flush();
                TCODConsole.checkForKeypress();
            }
        }
    }
}

There is a lot of work to be done, but the idea appears to be sound! I'll post more when I get the proof of concept fleshed out more.

Bringing cmake to libtcod - Last bits of polish

2010-03-12T19:04:00.000-08:00

(Your regularly scheduled blog posting about c# and magecrawl will return shorting, this is the last post scheduled to deal with cmake and libtcod.)

The last major issues I believe have been worked out. With the exception of osx support, which libtcod didn't have up to date in the first place, and some documentation I'm planning on writing tonight, cmake support is finished.

I finished up upx support last night, and spent today breaking up the build files into libtcod and sample parts, which makes everything much more clear. Overall, despite my gripes last night about its documentation, cmake is a great build system. It is vastly better in my opinion than makefiles, and the only build system is comparable in features is scons.

If you're writing a roguelike (or anything really) in C/C++, and consider cross platform important at all, I'd take a look at cmake.

Bringing cmake to libtcod - Why "use the source Luke" doesn't mean you can skip documentation..

2010-03-11T20:29:00.000-08:00

I'm going to start this quick post off by saying that cmake doesn't have the worst documentation ever. I'd generally award that honor to the C# swig documentation.

However, the documentation for cmake leaves much to be desired. Throughout my work, I've found most of my help with Google and other peoples submitted scripts. I'm going to try not to be cynical and assume that this is due to them selling a book.

Anyway, it seems that the upx for cmake documentation just doesn't exist. ~~I can find nobody on the internet using it~~. *Edit* I found one person here but it isn't working for me. At this point, I'm digging into the source of FindSelfPackers trying to figure out what I need to tickle to get it working. While this is better than the situation if cmake was closed source, it saddens me nevertheless.

(/endrant)

As the maintainer of libtcod-net, which is only somewhat documented, I realize this same complaint could be leveled back at me. If you happen to find yourself cursing the documentation of libtcod-net, please let me know.

*Edit-2* Since apparently I have a high google rating for "upx cmake" and I've found my solution, I'll post it for any future googlers. I gave up on using the built in finder, and am just using the one visible from the prompt. I'll have to variable it out to work on windows, but it's "good enough".

samples_c being the name of one of the outputs:
        ADD_CUSTOM_COMMAND(
            TARGET samples_c
            POST_BUILD
            COMMAND upx samples_c
            VERBATIM
        )

Bringing cmake to libtcod - Almost there...

2010-03-11T06:15:00.000-08:00

From my original list:

~~Build the example programs~~
~~Add back opengl support~~
~~Test linux~~ (and mac if I can get ahold of one) ~~builds~~.
~~Seperate C and CPP libraries for linux.~~
~~Install build stuff to root directory~~
A list of nice to have.
Documentation! ~~Quickstart guide!~~
Work on issues provided by and try to convince maintainers of libtcod that cmake is better.

Ignoring the mac build, which I still don't have, I only have the "nice things to have" (upx, ~~electric fence~~), documentation, and some cleaning up to do.

CMakeLists.txt is now ~~160~~ 163 lines of text so far. Compared to 1209 lines of makefiles it's doing the job of, its currently 7 1/2 times shorter. It is also one place to update the new/deleted files, as opposed to 8 makefiles + a codeblocks project that exists somewhere.

Assuming upx and friends don't take forever, I'm figuring one more good afternoon is all it will take to get a passable build done.

Update: Scratch electric fence, it was a 3 liner over breakfast.

Bringing cmake to libtcod - And then there was Linux

2010-03-10T07:00:00.000-08:00

Since my last post I've accomplished a few things. One of them includes:

The sample programs were ridiculously easy to move to cmake. Almost one liners in fact.

Beyond that, opengl has been added back. That was pretty easy, find_package has to be the coolest macro in cmake.

Linux support happened this morning. Other than some bashisms in my script to generate the cmake files, all it took was a few more find_packages to use the system headers/libraries.

Last thing of note was a quickstart document was written up, to get people started using cmake if they want to try it out. On libtcod's SVN head, its cmake/QuickStart.txt

Still a lot to do, but I'm getting there.

Bringing cmake to libtcod - First Successes

2010-03-09T07:01:00.000-08:00

I just checked in cmake files that will build libtcod and libtcod-gui under both visual studio and msys/mingw.

I still have a laundry list of things to do left including:

Build the example programs
Add back opengl support
Test linux (and mac if I can get ahold of one) builds.
Seperate C and CPP libraries for linux.
Install build stuff to root directory
A list of nice to have.
Documentation! Quickstart guide!
Work on issues provided by and try to convince maintainers of libtcod that cmake is better.

But I am happy with what I've accomplished so far.

A truckload full of random updates...

2010-03-08T17:08:00.000-08:00

So it's been more than a week since my last post, which is more than twice what I strive for (1.75/week). A variety of reasons are to blame for this, so I figured I'd comment on the relevant ones.

Illness - Have to love the times of year when everyone in the office seems to get sick.
Dragon Age - I just finished this game this weekend. I'm in the weird position of really really enjoying the game, but suggesting that others not buy the game and boycotting the expansion myself. The game comes with DLC (downloadable content) that requires authentication against EAs server to use. I didn't know that when I purchased the game. That means if you download the new armor and character, you can't play single player if you don't have an internet connection. Considering the problems that this can cause, I refuse to support games that do this.
libtcod - The base library that Magecrawl is built upon (via libtcod-net). While working on a bit of research that I'm not ready to open the lid on, I came across the build system, which is makefiles. Since my last post was a rant, I'll spare you the feeling on make. I'm working on adding cmake support, and was making great progress before getting sick. It's my goal to finish that before continuing work on Magecrawl.

The joys of software activation. (/Sarcasm)

2010-02-27T08:55:00.000-08:00

(This post has nothing to do directly with magecrawl nor programming. Blogger doesn't apparently like pseudo-xml tags in the title or the post).

So this morning I woke up hoping to get some work done on magecrawl before I had to leave for Houston for the weekend. I log into my machine to find the background is black and a popup telling me my copy of Windows isn't "genuine". I find this amusing, since I have MSDN at work and am pretty blasted sure I used one of those images for this machine. It's the machine I use to VPN into work when I work from home.

Well, I so find the spot on "My Computer"'s properties to ask it to try to validate again, and it fails. Alright, I'm not sure why it's failing, I'll go grab another valid product key off MSDN and try again. Which I proceed to do, still doesn't validate. Sigh, so I kickoff another download of the 4 gigabyte Window ISO image off of MSDN.

So on Sunday when I return, instead of programming I get the fun of reinstalling Windows and all my applications. Less hacking on magecrawl time for me.

(Rant)

I understand the concept that Microsoft is a business and it needs to make money to keep paying people to improve things. I didn't pirate Windows, I have a blasted valid product key. Well, up to of them 10 it seems. What is frustrating is that me, one who didn't steal anything, is being called everything but a thief.

I love C#, I think it is the best programming technology out there right now. Using visual studio when programming C# is so easy that I don't even reach for gvim most of the time. But now, because Microsoft decided to audit my machine overnight without my permission, I get a black background, an annoying popup, and an afternoon of work, even though I didn't do anything wrong. If I would have used a pirated version of Windows, I bet I wouldn't be having this problem now.

I'm in the laptop market sometime this year, and I was deciding between a new Dell an a new Macbook Pro. Getting a Macbook Pro and installing Mono Develop on it is starting to sound very good right about now. They might cost more, but I hear they never call your a thief.

(/Rant)

Review: Dance of Death

2010-02-25T18:27:00.000-08:00

As is every so often when I come across a game that looks interesting, this is a review of "Dance of Death", a flash game that was mentioned on RGRD. It's a "tech demo" at this point. As a flash game, it's very difficult to have issues getting the game to run, point your browser at the link and go.

The first thing one comes across when they start the game is in the title screen, and then the character creation screen. I like the tabbed panels with shading, which makes it somewhat obvious when one is done. One issue I came across is that one can tab over a panel without spending its points and type a name to finish. Doing this will create a massively underpowered character, and being able to do so is most likely a bug.

Since this game follows the standard practice of asking for name/race/stats/skills before the game starts, please don't consider it a criticism of it in particular. Games that do this ask the new player to answer questions they most likely don't have answers to yet. If I've never played before, how do I know what stat distribution I should use. Without playing the game, I have no idea of the usefulness of various skills, and so figuring out a skill distribution is difficult. I'm planning on the future of posting an entry entry on this point, so I digress.

Beyond that, the character creation does a decent job at explaining what skills do as I distributed stat and skill points, so I created a melee fighter.

The game has the feel of nethack in terms of room layout and color scheme (mostly white on black). Starting off on floor 0 was a bit humorous, as all real programmers number arrays that way (but maybe it should be floor 1). Controls seemed easy and expected. There was no diagonal movement, bump to attack was obvious and expected. Bump to open doors also worked as expected.

Field of view, monsters with pathfinding, and equipment all are there. Each "slot" of equipment seems to have a single item type, and I'm unsure it does anything at this point. It seems that inventory "Examine" is broken, but beside that everything works as expected.

The map generator seems to generate reasonable rooms with doors and stairs. Monsters were a bit sparse for my taste.

There is a "Skills" pane that show your skills and attributes, along with an exp pool. It appears to be just stubbed out for now, and shows some of my stats as negative, which is amusing.

For the first "tech demo" of this game that I've heard of, consider me pretty impressed. Development can be followed at the development blog here. I'm looking forward for further development, fleshing out what this game has to offer beyond infrastructure.

It's amazing I wrote some of this old code...and yet I don't regret it.

2010-02-24T18:17:00.000-08:00

Another of the mini-goals of this iteration was to provide a "Welcome/Title" screen to magecrawl, allowing the player a place to enter a character name and choose between save files. As I might have mentioned before, this "attempt" at Magecrawl is not my first. I've written parts of my game before in C/C++/python before a settling on C#. My wonderful wife has heard more than one time about me throwing everything away and starting again (or wanting to). I had the title/welcome screen from a previous attempt laying around in an old svn account, so I figured I'd salvage that as a good place to start.

My goodness, if I didn't know for sure I was the author, I'd want to disown this code. Ignoring the horrible style of capitalization and spacing I must have once liked, I've found multiple WTF moments. See this. One involved a corner cases with the color scheme that sometimes overflows into an exception. One was a half a dozen lines of code trying to reinvent Path.GetFileNameWithoutExtension(), and doing it poorly. The other memorable one was me declaring an enum to record what menu item we were pointing to, then ignoring it in a half a dozen places and comparing directly against (0,1,2). I hadn't given the enum a numerical set of values, so it just "happened" to work.

There is a proverb in Go that says, "Lose your first 50 Games as quickly as possible". The idea is that in the beginning, you don't know what you are doing, so don't overthink your moves. After 50 games, you can begin to see what looks like a good move and why people play as they do.

I'm starting to think the same idea might be valid for programming a roguelike as well. Experience has taught me, and while I wouldn't suggest throwing all your work away over and over again (like I did), just getting out there and coding will make you a better coder. While I haven't entered a 7 Day Roguelike context myself, it sounds like something I'd suggest and should do myself in the future.

Lightning Bolts, Fireballs, and Blasts of Winter - New spells types

2010-02-21T20:41:00.000-08:00

This weekend I did get a day to hack on Magecrawl some more, this time with user visible features. I added new spell types and targeting feedback to help you aim and you cast primal arcane might upon your foes.

The first type of spell isn't technically new. Lightning bolts (or any type of possibly bouncing line blasts) were in the tech demo. However, the aiming "halo" makes aiming them much easier.

"Cones" are easier seen than explained:

And what self respecting mage wouldn't have a fireball spell up their sleeve.

The evils of duplication and DRY...

2010-02-18T21:59:00.000-08:00

For those who've taken formal software engineering education or have programmed as a career, this post might something you've already heard of. However, I found myself coming back to this principle again while working on some code, and I figured it deserved a post nevertheless.

DRY: "Don't repeat yourself". Originally formulated in Pragmatic Programmer (a great book I read as an intern), this guideline for software development is simple and to the point. The idea is that you should never have two places that contain duplicate representations of any given fact.

The most obvious implication of this is that you shouldn't copy code. If two places need a given chunk of functionality, abstract it to a base class, static method, helper class, etc. At work, I've heard this copying known as the "editor inheritance" pattern, the "editor" being your text editor.

Even if you don't copy paste your way into this situation, it is easy to run into in other ways. In magecrawl, the two ways to invoke a spell-like affect is via the "Cast Spell" screen and selecting an inventory item and selecting the use verb. I found that keyboard handler for both these screens were 99% identical. In the beginning, spells and spell like affects had no targeting possibilities, they always targeted the player. As I added targeting, I added it to both places not realizing the duplication. This became a problem when I wanted to add a new targeting type later on and nearly missed one of the two copies.

I find that when I find these areas, the best thing to do is address it either "right now" if your in development, or as soon as the next release occurs if your stabilizing for a release. I shelve whatever changes I was working on, and figure out how to remove the duplication. In my case above, I created a base class that contained the common code and had both classes inherit it. I then tested it thoroughly and submitted it before working on new features. Your refactoring hat and your new feature hat shouldn't be on at the same time, you look silly when you try. :)

The more advanced implications of DRY involve not repeating yourself in more than just near identical code. The book mentioned above handles some of those cases, and maybe I'll come back to them in some future post (when it isn't nearly midnight as well).

Taking damage, how to represent health and armor in Magecrawl

2010-02-18T19:11:00.000-08:00

Since I've got some downtime tonight and don't have access to my programming computer, I figured it'd be a good time to write down my thoughts on health and armor. But before that, I must ask that you read this:

TVTropes - Critical Existance Failure

This is one of the things I'd like to not do. Nearly every roguelike has a system that boils down to this. In Crawl and Nethack, and nearly every game in between, there is no difference between 100/100hp and 1/100hp. While convenient in its simplicity, it bugs me. On the other extreme end are games that track damage to every single limb, with slow healing that while makes the game "tatical", it also makes many unplayable in my opinion.

Beyond the "one hp issue", there are other issues that need working out. Another is the randomness of combat in current Magecrawl. Armor has a chance to reduce the damage taken, and when added to the evade percentage, the player can go many rounds without taking damage and then suddenly loose half their hitpoints in a round to a "lucky" double strike.

I haven't fleshed out all the repercussions of this idea, but here's what I'm thinking. The health of the player is divided into three parts over two bars:

Health - The lower end of the first bar. These are hitpoints that don't naturally regenerate over time. Only magical healing or long rest could heal these. They represent actual wounds, broken bones, and the such.
Stamina - The upper end of the first bar. These are the hitpoints that regenerate outside of battle. The outside of battle part is to prevent Pillar Dancing (which beyond Elbereth is one of the cheesiest tactics in my opinion). Better armor will increase this amount (almost with some type of damage reduction and/or increased MP cost for spells). These represent ones ability to stay out of true mortal harm for some part of combat.
Shields (for lack of a better name) - This would be the second bar, only shown when you have an affect that provides it. In most RPGs, spells like "Mage Armor" act the same as regular armor. I like the idea of it being forcing back damage due to your arcane will alone. When a spell that provides protection is active, this bar would be populated with a set of temporary hitpoints that take (some? all?) of the damage before stamina/health is taken from. It's length would be based upon spell proficiency, intelligence/willpower. I like the idea of it sapping from your mp during and after battle to recharge itself, giving it different flavor than stamina. I'm not sure how to get around Pillar Dancing if I do that however, unless it only does that when you don't move.

Beyond this, there has to be some penalty to taking some damage, beyond chance of death. I like the idea of stamina damage either slowing down your CT (longer time before turns), increasing MP cost of spells, or both. Health damage should be more crippling, such as slower movement, penalty to MP regeneration, and such.

I'm trying to balance this with keeping the game fun. I'm hoping in this iteration to get some implementation of this system in and see how it plays. Any thoughts?

Getting bogged down a bit...

2010-02-18T07:02:00.000-08:00

This week I've been getting bogged down and not finding much time to work on magecrawl. Some reasons for that include:

Dragon Age - which for the linear story-driven RPG genre is an amazing game.
Winter Olympics
Plant vs Zombie - humorous and well polished tower defense game.
Illness, my wife wasn't feeling well this last week and I've been fighting a bug as well.

Beyond that, it looks like the next bits I'll work on in magecrawl will include more fleshing out of magic and equipment. The magic work will add "Fireball" like exploding spells, "Cone of Cold" like spells, and the like. In equipment, I'm looking to handle hp in a more unique way, add shields, and one/two handed weapons.

Frustration with "stitch" map generator...

2010-02-14T21:14:00.000-08:00

As I continue work on iteration 8 when I get a chance, I'm becoming somewhat frustrated with my "stitch" map generator. To understand my frustration, here is the 10000ft view of how it works.

A graph of "nodes" is created, using probabilities from a map. That graph is dropped one node at a time onto a large "map", with the nodes next to each other in the graph next to each other. "Dropping" a node involved looking up one of multiple templates from a text file of that type, and placing it so the seams line up. If a node can't be dropped, we add it to a list of nodes we can drop later if we run into a room that doesn't have an output assigned. There is come complicated logic to prevent us from dropping a long group of halls and then being unable to place the endpoint room from leaving the hall. Once we have the graph generated into rooms, the map is "trimmed" so it isn't larger than it needs to be, checked for connectivity, and in/out stairs are placed.

The flaw in the system that keeps biting me over and over again is the separation between the "graph" and the actual map. It makes some things that you'd think were easy, such as dropping doors between rooms difficult. The latest thing I was trying to fix was the fact that the map looked like a spreading tree (since it was). Once you went down a hallway, you'd never reach any of the rooms in any of the other hallways. My idea was to patch this by finding empty "seams" in rooms and trying to draw hallways between them if possible. After burning an hour, I'm frustrated since by the time I've reached the hallway placement stage, I've lost all the information on the map structure and which nodes I'm working on.

I've booted the feature to iteration 9, and in that I'll decide if I want to refactor this map generation to something easier to work with or rewrite it new. Does anyone have any references to map generators that produce great looking maps with hallways, rooms, and such?

Targetting, bump to attack, and player's preferences...

2010-02-09T18:04:00.000-08:00

Some of the feedback I received during the last tech demo includes a few complaints that when they'd hit 'a' to attack, the screen centering on the first available target was disorienting. While I personally didn't have this issue (or else I'd have coded it differently), I could see where they were coming from. Since I'm handling "low hanging fruit" early in this iteration (or procrastinating, depending on your point of view), this seemed like an easy thing to handle.

I've covered this issue with two different fixes. The first being the inclusion of "bump to attack". This is a common feature in roguelikes, where moving into the same space as an enemy invokes a melee attack. I personally don't care for it. I've lost more than one character in games without "run in direction" when I held down an arrow key for a half a second too long and melee'd myself into oblivion.

Magecrawl also has weapons with "reach" such as the spears, and bump to attack can prevent people from noticing their longer reach. In addition, some weapons either can't attack certain directions, or attack at lower strength; the attack key shows overlays making both these facts obvious, while bump to attack doesn't. Despite this, it is a convenient option, so I added it as a preference one can turn on.

The second fix is a preference to disable all "auto targeting". When you request an action that requires targeting, magecrawl will try to pick an intelligent initial targeting position. This preference just skips all this code, and all targetting starts at the player's position.

I'd like to spend a minute talking about preferences. Magecrawl isn't even a full game yet, and in addition to keyboard settings for every key, magecrawl has more than 15 preferences so far. A few are debugging settings, but most are documented in Preferences.xml. Each of these brings different behavior to magecrawl in some manner, which in theory requires additional testing and maintenance. The trick is to find a balance of providing great defaults, so people don't have to touch the preferences, and enough knobs that people can change the settings that are important to them.

libtcod-net 1.5.0rc1-2 released (fixes reported TCODRandom issue)

2010-02-08T18:09:00.000-08:00

The issue reported here has been debugged and fixed. The short answer for those not interested in the details is that I was using an API in libtcod wrong and that API was doing the wrong thing and corrupting its internal state. Get the newest libtcod-net here.

For those who are more technically minded, here's the story.

In between libtcod 1.5.0b2 and 1.5.0rc1, the C API changed for creating TCOD_Random's. Previously, one could call TCOD_random_new(), however in this release they added two different RNG implementations. This function now take a paramater. The way to get the "default" RNG is to call TCOD_random_get_instance, which I did happily. I also added a new TCODRandom constructor that took the enum for those who cared, but that's beside the point.

This worked, and seemed to be all I needed to do to fix libcod-net TCODRandom for the new API. However, there was an underlying issue. Sometimes in magecrawl, monsters and players would get into long stretchs (4000+ turns) of continual misses.

After some detective work, the issue was found. TCODRandom, like all libtcod-net wrappers that handle unmanaged resources, implement IDisposable. The idea is that you, or the runtime, will call Dispose() on it to free the allocated memory. The issue is that the new api had a note that you weren't supposed to call TCOD_random_delete on the default RNG. When you did this, you free'ed the memory for the global instance, but not null it out. Due to the implementation of the RNG, it'd happily use the garbage memory giving random answer most of the time. Some times however, some of the garbage pointed to a segment of zero'ed out memory, and I'd see the long stretch of zero's.

The solution was twofold. I updated libtcod-net to follow the API's rules and not delete the default RNG if that was how we implemented it. jice updated libtcod to not internally corrupt itself if you happened to do this. The joys of maintaining libtcod-net is that sometimes you get to track down memory corruption issues, even if you're written in c#. That is the fun of interfacing with unmanaged code.

libtcod-net 1.5.0rc1 seems to have an issue with TCODRandom, beware.

2010-02-07T20:53:00.000-08:00

Update: See this for a solution.

I've spent half of today debugging this issue. It appears that there is an issue I'm hitting in magecrawl where a TCODRandom gets stuck in a state where it returns 0's for every GetRandomInt call. I'm working with the maintainers of libtcod, but it appears the issue is one underlying libtcod itself.

The workaround is to use the constructor that takes an enum and pass is the MersenneTwister value.

I'll update more when we find out more. I just didn't want anyone else to try to debug into their code for a few hours looking for sensor ghosts.

libtcod-net 1.5.0rc1 released!

2010-02-07T12:30:00.000-08:00

libtcod-net 1.5.0rc1 has been released (same day as base library libtcod itself may I add :) ).

The major changes include TCODPathFinding being removed. It's been split up into TCODAStrPathFinding and TCODDijkstraPathFinding. This is obviously an API break, but one that can be replaced with a simple find a replace. Beyond that:

TCODSystem::GetCurrentFontSize
New random number generator type and new default (ComplementaryMultiplyWithCarry)

New functions - GetGaussianFloat, GetGaussianInt, Save
Removed functions - GetIntFromByteArray

ResetCreditsAnimation, which fixes an outstanding bug in Magecrawl.

Get it while it's hot. Thanks jice and team for another awesome release to build upon.

http://code.google.com/p/libtcod-net/