Tuesday, May 25, 2010

Magecrawl Tech Demo III release for Windows/Mac

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

    Friday, May 21, 2010

    Balancing combat is hard, Let's go shopping!

    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.

    Thursday, May 20, 2010

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

    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.

    Tuesday, May 18, 2010

    Skill Tree Complete for Iteration 8

    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.

    Wednesday, May 12, 2010

    More Skill Tree Goodness

    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.

    Monday, May 10, 2010

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

    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

    Tuesday, May 4, 2010

    Skill Tree Initial Work

    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?

    Sunday, May 2, 2010

    Magecrawl Title Screen

    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.