Pages

Monday, November 19, 2012

The Robe and the Wizard Hat


It's been a while since the last update, and quite a lot of things happened, so this will be another rather long update. I really should do these more often so they don't end up so huge.

First up is feats. The vast majority of them are done. Out of the 170ish (give or take a few) feats I entered in the game's database when I started working on the feat-selection board earlier in June, all but 9 of them are completely implemented.


I've also added something which slipped my mind before - characters all had races, but I had forgotten to address the issue of racial types and subtypes. Ogres, Tolls and Hill Giants are different races, but they all belong to the Giant type, for example. So I went ahead and implemented that, which also allowed me to complete all of the racial feats, such as the Dwarven Defensive Training feat, and the background feats I've mentioned in earlier updates, which allow you to assign a unique bonus to each character on character creation.

Additionally, all core combat actions (e.g. Bull Rush, Fight Defensively, etc.) are now available, including ones based on class-specific feats:


This means that all melee-centric classes, like Fighter, Barbarian and Monk are essentially finished. The feat menu in particular took some effort to implement correctly. Unlike the other combat menus, it fills itself dynamically on a per-character basis, depending on what feats the given character has available. It also takes into account feats which have a fixed number of uses per day, such as Rage and Stunning Fist.


A few feats have also been renamed to more accurately reflect what they actually do: Called Shot is now Power Shot, One Shot is now True Shot and Manyshot/Greater Manyshot are now Double Shot/Improved Double Shot. I've also tweaked the behaviors of some feats to work a bit differently from their PnP counterparts: Expect Tactician works closer to the Neverwinter Nights 2 version, rather than the D&D3.5e version, while Manyshot is closer to the Pathfinder implementation.

I've also rewritten some of the targeting code to be more flexible: I noticed some inconsistencies with the earlier version due to how distances were being determined.


Now, whenever an ability has a circle-shaped (technically spherical, but we're only concerned with 2D here) effect radius, it's possible to specify to the intersection function whether tiles should have a) their center inside the circle, b) any corner inside the circle or c) all 4 corners inside the circle. This is important because even though the tile system itself purely integer-based, all of the ranges and distance calculations are still performed  in real coordinates internally, to preserve accuracy.

Another area that's had some progress was Status Effects. I improved some of the existing functionality to allow status effects to display their remaining duration along with their icons:


Effects with unlimited duration (e.g. toggled modes, like Power Attack or effects that don't wear off on their own, like Ability Damage) have their duration displayed as "∞". This now happens wherever they're displayed, be it in the status menu or above character panels in combat.


While I was in the right frame of mind to work on graphical improvements to the game, I've also added more feedback to various actions in combat by providing more information in the Combat Log:


Finally, I refactored the way classes were being stored. When I created it, I only had a very small amount of data to store and rarely had to look it up, so it was just kept in 2D arrays. With all the new class-specific behavior that I've been introducing, it became a massive pain to write a 5~10 line block of code every time I wanted to check whether a unit had levels in a given class, or what its class level was. So I rebuilt the whole thing; it's much easier to use now and most checks that used to be O(n^2) and required a several lines of code to make, now are O(n) or constant time and require only one or two lines to be written (and it's much more readable).

Finally, with the vast majority of work on Feats out of the way, I tackled the final major combat-related feature that was missing from the game: Spells!

Originally, I thought this was going to take something on the order of a month to implement because there's just so much to do. Properly implementing spells is something that touches practically every part of the game I've worked on so far: leveling, character creation, the internal actor(and enemy) structures, several menus, several parts of the database, and most of the combat system.

This is where flexible code pays off. Whenever I build a big system - the leveling system, for example - I try to make it flexible enough so I can not only maintain it easily in the future, but also make additions to it without having to rework the whole thing, or copy-paste large sections of code.

Thankfully, it seems I've done a pretty decent job at that; when I went back to some of my older code (some of it going back to about 4 or 5 months ago), it was actually fairly easy and quick to add all the spell behavior into everything - despite the fact that I figured out how exactly I wanted to implement them only recently.


So with that, I've added in all of the remaining core classes in the game, as well as most of their particular intricacies, such as differences between spontaneous and prepared casters.


There's still quite a lot of work to do, of course - even with things moving dramatically faster than I expected, it'll still probably take me another two weeks or so to have all of this properly working. But at the moment, the leveling process is working for all the available classes: you can learn spells, earn spell slots, get caster levels, increase the number of spells per day available, etc.

I've also done most of the work that was necessary in the Spells section of the main menu:


Spells can be viewed, assigned slots and removed (when applicable), as well as having correct behavior for multi-classed characters, which will have several spellbooks; it's perfectly possible to have multiple classes with different progression (e.g. a multiclassed Wizard/Cleric), classes that add progression to the same spellbook (e.g. a Bard/Virtuoso character) and classes which have different spellbooks which are drawn from the same spell list (e.g. Wizards and Sorcerers).

I still have to go back and add proper behavior for spellcasting classes during character creation (which thankfully won't be terribly hard, it's just a special case of the normal leveling process, which I've already completed), spend some time in the database adding all of the spells I plan on having for an Alpha or Demo version of the game (probably only core spells up to 10th caster level - which is still a huge number of spells), and finally add the ability to actually use spells in combat.

I'm glad Thanksgiving is coming up soon - I could use the free time to get more work done! I'm aiming to have most of the scaffolding required for the core aspects of the game done by the end of the year, so I can start working on getting an Alpha version out for people to play. I really want to start working on playable content as soon as possible. With any luck, I'll have something that actually feels like a proper game - rather than a collection of features - out by January next year.

Friday, October 26, 2012

Status Effects, Art and Music

I think I'm finally starting to get back in the groove after my break; I was getting good work done during my last update, but I've really picked up the pace in the last couple of weeks. So here's another status update, and this time it's a big one.

First of all, we now have status effects!


They're visible in the bottom right corner of the main menu, where all the placeholder status icons used to be. As you can see from that screenshot, it's a scrolling window now, meaning you can move the cursor over to it and see however many status effects you're affected by.

Not only that, but I've also re-worked the Summary menu help window to look a little cleaner and function with the newly implemented status effects, giving you some pretty detailed information about what's going on.




This was actually quite a bit of work. If you've ever used RPG Maker, you know it doesn't actually support storing all of this information about status effects anywhere. To get this to work, I've actually implemented a completely different system to handle the game's status effects.

A base class defines all the common features of status effects - applying/reappliyng/removing/etc. , as well as their interface.


Each effect is then represented by a class that inherits that, which can then have whatever behavior I want it to have, and hold whatever information I need it to hold. The fact that I can no longer edit them from VXA's database is a small price for the huge amount of flexibility I get with this.


The following effects were implemented:
  • Flatfooted
  • Prone
  • Fatigued
  • Exhausted
  • Nauseated
  • Asleep
  • Dazed
  • Stunned
  • Fascinated
  • Blinded
  • Deafened
  • Entangled
  • Shaken
  • Panicked
  • Paralyzed
  • Unconcious
  • Dying
  • Dead
  • Haste
  • Slowed
  • Ability Damage (Strength, Constitution, Dexterity, Intelligence, Wisdom and Charisma)
  • Disease (Red Ache, Shakes, Mummy Rot, Mindfire and Cackle Fever)
  • Poisoned (Aranea Venom, Huge Spider Venom, Colossal Spider Venom, Ettercap Venom, Arsenic, Giant Wasp Poison, Phase Spider Venom, Black Lotus Extract, Epic Wyvern Poison, Id Moss, Striped Toadstool, Chaos Mist and Ungol Dust)

These all include most of the various special D&D rules regarding combat behavior while under these effects, such as not being able to Run while Fatigued, and Ability Damage recovering slowly every time you rest.

I haven't implemented every single disease and poison effect in the D&D3.5 SRD because for the most part, I think it's unnecessary (there are dozen and dozens of them). I've included at least one affecting each base ability score, so they all have their own specific purpose. I might add more later if people really think it's necessary, but for now I think a handful of each type should be more than enough.

One other interesting thing to point out, which I realized while developing this whole system for status effects is that in general, the duration for any given effect varies based on how it was caused. Spells, for example, have a duration that's usually based on the caster level of the unit casting it. On top of that, there's other things which can modify it, like Metamagic. So I need some way of saying "by the way, this Haste spell has Extend Spell on it and lasts longer than normal!".

Thankfully, there is an easy way to do this in Ruby, though it requires a little bit of work to setup. Thanks to this post on StackOverflow, I've found out that you can actually model enums as objects in Ruby and use them to represent bitflags. So I can write something like this:


Then all I have to do is pass this around, if say, I want to have a spell with Empower and Maximize on it:


And checking it becomes trivial:


This makes handling all of the various possible ways status effects can behave actually fairly easy. That's about all that's been going on in that front. After wrapping up status effects, I resumed working on the combat system and started filling out all of the previously unimplemented actions. All of the following are now available in combat:


  • Aid Another. Minor change: all Aid actions have been fused into a single action. This means that whenever you "Aid" an ally, they gain both the AC bonus and the attack bonus. Additionally, if they're Asleep or Fascinated, those status effects are removed. This helped me get rid of the clutter from the combat action menu; three different Aid actions was too much.
  • Trip
  • Disarm. Minor change: when a unit is disarmed, their weapon automatically gets returned to their inventory, rather than being dropped on the ground per PnP rules. This means the target can re-equip their weapon after being disarmed, though it will use up their action for that turn.
  • Coup de Grace
  • Feint. Minor change: any unit that attacks the target gets the bonus, not just its user. The effect still disappears as soon as target is hit, regardless of who hit it.
  • Total Defense
  • Run
  • Charge
  • Bull Rush

With status effects available, most of these were fairly straight forward to implement, with a coupe notable exceptions: all the actions that depended on moving in a straight line (so Run, Charge and Bull Rush) required a little more effort.

The problem comes with how I've been handling movement so far. Until now, I've been using a modified version of Dijkstra's Algorithm for path-finding, which works out really well for a tile-based engine like RPG Maker, because a network of tiles can be easily represented as a graph. It's great whenever you need to find the shortest path from A to B, while avoiding any obstacles (i.e. impassable tiles, tiles occupied by enemies, etc.) on the way. It's not very good at straight lines, though.

How would you use it to get the tiles represending a straight line from any given tile to any other tile? The algorithm explores the surrounding tiles in a breadth-first fashion.

The thing about straight lines is that - outside of directly going in one of the 8 directions - it's actually non-trivial to figure out what the "straightest" straight-line path is from any tile to any other tile. So I needed to come up with a way of mapping any straight line, in any direction or angle into actual tiles. Turns out Bresenham's Line Drawing Algorithm is perfect for doing exactly that.



So I wrote a second path-finding algorithm based on that. Given any two tiles, it will find the most optimal way to turn a straight line between those tiles into an actual walk-able path of tiles, then check whether that path can be traversed. The only minor wrinkle in it is that the algorithm was originally created to draw pixels on a screen, and you generally don't care about in what order that happens, so sometimes it gives you the list of points out of order, depending on the slope and direction of the line.

I do very much, however, care about order when walking on tiles in a path, so I've had to make some minor adjustments. Given some fairly simple changes, though, the whole algorithm works out quite well.

Finally, I've made a few changes on the art & design front. First of all, I've simplified a few areas of the game by getting rid of the Grapple mechanics (I think it's unnecessary and most people hardly every use it), the ability to run away from battles (Save often!) and I've halved the range on all ranged weapons.

That last one takes some 'splainin. The thing with RPG Maker that annoys me the most is the incredibly tiny resolution you're limited to. Since I'm essentially making a tile-based SRPG and measuring distances in tiles, this means I have a fixed amount of the game's coordinate space I can ever actually display on screen.

The means that even though some distances make perfect sense in D&D, they're actually really large when you move them to RM. For example: ranged weapons have 3 (roughly) important ranges: 30ft (hand crossbows), 60ft (shortbows) and 100ft (longbows). If you represent each tile as 5x5ft, those turn into ranges of 6, 12 and 20(!) tiles away, respectively.

If you've ever made a map in RMVX or VXA, you know that's a lot of tiles. For the sake of comparison, you can only actually fit a region of 20x15 tiles on screen at any given point. So a longbow would always be able to reach anywhere visible on screen, and then some. That's way too much. I can't ever imagine having combat maps which are big enough for that to actually be relevant. So I've decided to half all of those ranges, bringing them down to 15/30/50 ft - or 3/6/10 tiles, respectively.

I think that's a much more reasonable scale. If you've ever played Final Fantasy Tactics, you'll recall that ranged abilities also had 3 major ranges: 3 tiles (wave fist, most sword skills, other melee ranged abilities), 5~6 tiles (bows, magic) and 8 tiles (guns). I think that's a fairly good scale.

Last, but definitely not least, the game finally has a logo and a title screen, thanks to Archduke on the RPG Maker Web Forums:



Speaking of RMWeb, I've also joined their Game Making Drive. I'll be posting daily updates in the Drive forum thread:



GO TEAM RALPH!

Aaand, that's all folks. Stay tuned for more updates. For now, I'll leave a hint of what I'm working on next:




Monday, October 15, 2012

A Break, more Combat Updates and...Art?

So, in the last couple of months I've taken a bit of time off to sort out various issues that prevented me from having quite enough free time to keep working on the project at the pace I had during the summer.

In the meantime, I took what time I had and decided to use it to go through other games similar to this project and sort of compare notes - see if there's anything I hadn't planned for or had forgotten to address. I did actually end up coming up with quite a lot of extra notes, but I don't want to quite post out here what they are yet until I'm ready to start working on them, which should happen after combat is mostly finished.

That time is mostly over now, thankfully, and I'll be getting back to work on this very soon. In fact, speaking of combat, I have a few extra updates to showcase since the last post I made.

First of all, I've completely overhauled the visuals. It now (hopefully) looks like a proper combat system, rather than a bare-bones tech demo.


There's now a combat log in the bottom right, which displays some basic information about all actions in battle, and the portrait windows should now be easier to read. In addition to cosmetic changes, I've also implemented several of the basic combat mechanics:


Characters can now use most forms of movement, including the basic move action, 5ft steps and the withdraw action. The blue set of tiles displayed is the character's basic movement range, while the yellow set of tiles are the squares they threaten.

Any unit walking within those yellow tiles will trigger an Attack of Opportunity, which has also been fully implemented. Units' threat ranges vary based on what weapons they currently have equipped.

As you can see from the screenshot, attacks have been implemented as well, both in the form of single attacks and full attacks. These all correctly handle two-handed weapons, dual wielding, double weapons and ranged weapons.

I've also implemented a basic targeting system. Each action that can be performed in battle has a particular type of targeting. The targeting system allows actions that target not only single tiles, but area effects in various shapes, such as circles, cones or lines of tiles. This will be more relevant once spells are implemented.

Combat can actually be finished now, so you could say this is the first time the game has an actual proper combat system. Experience is awarded based on the difficulty of each opponent defeated and split between the player's party. Additionally, enemies have their own inventories, and you automatically obtain everything they were carrying at the end of combat.


I've also added a few nice details to make the combat feel smother, such as a damage preview window whenever a player unit targets another unit with a hostile action. This way you have some idea of whether it's worth it to perform a given action before committing to it.

And that's all for now! Next up, I'll be implementing status effects so that actions like bull rushing and tripping are possible, in addition to the obvious applications, such as the ability to poison enemy units or buff allies.

I'm also looking into changing the game's art style into a more grainy, old school 2D western RPG type feel (think Ultima Online), provided I can get the support of an artist willing to put in the work.




I can't say anything for certain about that quite yet, and even if I do make the change, it won't happen for a while, but look forward to further news on that front in the future!

Wednesday, July 25, 2012

Combat Is Hard

Yet another status update! Before I get to that, here's a really quick progress video, showing off what I've been working on since last update - it's been a while since I made a video, so I figured it was time for a new one.



It's a short video, but you can get a glimpse of more or less everything I've been doing recently. You can see the world map in action - I think it looks a lot nicer in action (and with music!) than what you see from the screenshots I had previously posted.

As for the new things:


You may have missed it in the video, but I made a few minor updates to the main summary menu. The most important additions are:

  • There now are icons in the header for stats that weren't visible before. The staff with the red X on it is your Arcane Spell Failure chance (from wearing armor), the blue dashing guy is your Initiative score and the black icon on the bottom-right of the header represents your Armor Check Penalty (used when you're wearing heavy armor and try to use skills like Hide or Move Silently).
  • All of the new icons have tooltips, indicating where the final number comes from, in terms of your stats and equipment
  • Some of the old stats which didn't have tooltips now do. Notably, you can now see how your equipment is contributing to your carrying weight, and where your HP value comes from. If you pay attention to the video, the HP tooltip displays how much HP you're getting from your class. If you take more levels in that class or in a different class, the tooltip will display how much of your total HP comes from each level you've taken in all classes you've ever taken a level in. 
I'm a big fan of giving players all the (relevant) information you can, so I think these are all pretty nice additions to the summary menu.


Another small but important addition is loading screens. RPG Maker games are usually so small and have such tiny resources compared to a standard 3D PC game that loading screens aren't actually necessary, but I find that - if done well - they're actually pretty nice to have just to add more visual flavor to the game.

I'm not entirely sure I like the font color on the LOADING/SAVING text, but I'm pretty happy with everything else about how these turned out. I'll be using various D&D related images throughout the game. 

Which image you see is usually random, though I've also added code in to allow me to display a specific image (or a random image from a specific set of images), so that you'll generally end up seeing images related to what you're actually doing in the game. When you rest in town you'll see a different image from when you rest in an inn, and those will be different from what you see when you fast travel or enter a map that's part of a particularly important plot point. I think that when used properly, these can add a lot to the atmosphere of the game.


Finally - the big elephant in the room - the combat system! Well. Almost-combat-system. Since you technically can't actually have any combat yet.

This is where the bulk of the work has been going in during the last couple weeks for me. The UI is intentionally completely bare-bones for now: I'm still implementing most of how the combat works; I can worry about what it looks like later (I'd go so far as to say the visuals are the easy part).

What you see in the video is pretty much all I have at the moment. There's a turn-based system running managing combat, and you can see the turn order (which is determined by every combatant making an actual d20 initiative roll at the start of combat) by looking at the portraits in the top-left of the screen.

Most of the commands in that menu don't actually do anything yet; I just put them there to get a feel for how the menu layout will eventually look like once it's done, and as a reminder for everything I want to eventually get working in the game. Every single one of those commands will eventually be implemented and work the way you expect them to if you're familiar with what they usually do in D&D.

The AP bar doesn't mean anything right now, though it eventually will. I'm planning on using it as a visual representation of what you've actually done so far that turn. For example: in D&D you can move up to twice per turn (or move once then act once). So after moving once, your bar will be half full.

The three little axes on the bottom-right display are placeholders for, in order: whether the unit is an ally or an enemy (eventually will be some kind of blue or red icon, depending on who the unit is), how many free actions the unit can make per round and how many Attacks of Opportunity the unit can make this round.

There's a few interesting things I put in the system that I'm not really able to show off in a video yet, like the ability for enemies to have random names (picked from a list of several hundred). They also have their own inventories, which determine loot at the end of combat - so if you see an enemy wielding a Great Sword of Kitty Murdering + 4, you will actually get it as a reward once you kill him in a fight. If an enemy starts combat with a bunch of potions or spell scrolls, you can get them as loot if you kill it before they get a chance to use them. And so on.

That's about all I have so far. There's a placeholder for a status window (which will look something like the summary window in the main menu, but you'll be able to see them for enemies too), though I doesn't have much inside it right now, and there's some enemy AI (though all it does at the moment is "Think" for 4~5 seconds, then end its turn without doing anything).

The groundwork for combat is all there, now I just have to keep adding to it. I can see why people don't build custom combat systems that are too different from RPG Maker's default very often. I still have a very long way to go before this is proper D&D combat and it's already taken me a couple weeks of work and 7 scripts which together total about 3000 lines of code.

That's all for now. I'll be working on combat for a while, posting more updates every now and then, when I make progress significant enough to show off in screenshots or a video.

Thursday, July 12, 2012

EVO 2012!

It's been a little too long since my last status update, but here it is: better late than never, I suppose.

In case you're wondering, the reason for the delay is that this past weekend was EVO 2012 - the largest fighting game tournament in the world, held every year in Las Vegas - which I attended. I took some time off RPG Maker-related things for the last couple weeks to get a little bit of practice before going.




Now that that's over (it was incredible, by the way, you should watch some of the matches if you haven't done so already - KOFXIII and Marvel 3 in particular) - I can get back to work.

Despite the rather long break, I have actually gotten quite a bit done since my last update. The first major thing is that the game now has a Day/Night system.


Now, as simple and common as such a system might seem, it will actually have a significant effect on how you play the game. I don't want to give away too much just yet, but: in addition to the time of day changing, and the tint of the screen changing in outside areas, which actual day it is will matter as well.

The game will keep track of how many (in-game) days have passed since you started the game, and various events will happen differently depending on how soon or how late you trigger them. This will be a major influence in how the game's main storyline unfolds, and ultimately how the game ends. That's all I'm going to say about that for now!

Another thing you may have noticed is that in addition to a clock, the main menu now also has a World Map option. From there you can view the game's map, as well as fast-travel between locations you've visited before.



You can move the cursor around to highlight your destination, while moving it to the edges of the screen scrolls the map (which is actually quite large). For those without the patience to find their destinations' exact locations on the map (or for those times when you've simply forgotten), you can instead press X to open a quick menu displaying all your available destinations in a list.


Another new addition to the main menu is weapons and armor. The weapons & armor menus are now actually functioning menus, rather than placeholders, as they used to be.



All base (i.e.: non-magical) equipment functions as expected of a D&D 3.5 game, including the ability to Dual Wield smaller weapons, use larger weapons in two hands and Double Weapons having two separate attacks.

All equipment is unique, so you can have several different pieces of Chain Mail, for example, each with different extra bonuses. You can also press X while highlighting any piece of equipment to view a description window detailing its properties:



Another nifty feature is that the equipment you use will actually affect your character sprite's appearance in-game. So even if you have two characters which look exactly the same after you've finished customizing your appearance when you start the game, they will still end up looking different if you have, say, one wearing scale mail and the other wearing a helmet and a set of full plate mail:




Finally, I've completely reworked how I'm representing player attributes in-game. Initially, I was using the standard RPG method of assigning players some base value of, say, Strength, then in a separate structure I'd hold any enhancement bonuses they might have from, say, equipment or abilities.

When I started actually implementing equipment I realized how this didn't quite fit the way D&D handles attributes: there's an unlimited number of different bonuses that can be applied to any attribute, and you have to keep track of what bonus is of what type, because bonuses of the same type don't stack (with a couple rare exceptions).

With that in mind, I completely reworked how I model player stats. Now, every attribute is actually a hash table, which itself contains an array of values of a given type of bonus. The largest value is always used, but all values are stored, in addition to some meta-information on what's responsible for that bonus in the first place.

I like this because it's a much more faithful representation of how D&D attribute bonuses work, but also because it allows me to add new cool features like this:


That's what the status menu looks like (and has looked like for a while). Before, all you could do was look at it. Now, you can hit the confirm key and move the cursor into that window, like so:


And you'll get to highlight the core stats displayed in that window. Each stat you highlight has an associated tooltip which displays everything that's contributing to that stat's final value. In this case, your total AC is 17 - 10 from the base value every character has, and another 7 from your equipped armor and shield.



Bonuses are displayed in green, while penalties are displayed in red. In addition to bonuses from equipment, you can also see modifiers for certain stats, like your character's saving throws (which are modified by certain other core attributes).

And that's all I have for now!

Next on the schedule, I've actually decided to put off some of the things I detailed in my previous post (such as autosaves and minimaps), since I don't think they're terribly important to get done just yet.

Instead, I'm going to start tackling what is probably the most important part of the game: the combat system. It is, after all, the biggest part of the core gameplay and I haven't even started working on it yet. I've also gotten all the major requirements for some basic combat done (i.e. characters have equipment, stats, feats, etc. - they're more or less ready for combat in every way outside of having an actual combat system).

That's probably going to take a while, but once I have that done, this will feel a lot more like a proper game, I think. Then I can start working on the smaller things - like the minimaps, the autosaves and the quest system.

Wednesday, June 20, 2012

Feats: Status Update

After spending quite a while tweaking how the feat selection works, I can say I finally have a solid v1.0 of it going right now. Take a look:


In addition to the feat trees, the video shows a glimpse of a few additional feature's I've just added, namely:

  • Character backgrounds. I've always really liked the idea behind the character background feats in Neverwinter Nights 2, but always felt they were way too weak; their bonuses too small to make any difference.

    In D&D 3.5, you can take something called character "Templates", which work something like NWN2's backgrounds, but those were on the other side of the power spectrum - they tend to produce over-powered characters.

    I've implemented what I think is a reasonable middle-of-the-road solution. If you don't know what I'm talking about, a background is basically a quick nod to what your character might have been like before the game started (which you get to decide), and this background provides him or her with a fixed bonus. You can only take one, and only at Level 1, during character creation.

    Bonuses you'll get range from +2 to a particular stat, +2~4 to one or more skills or some other unique bonus like being able to move 10ft further each turn if your background is Athlete, or giving your allies +1 attack while lowering your own by the same amount if you're a Natural Leader. I think it adds a nice amount of flavor to character creation, especially when the bonuses you get will be large enough to actually be relevant in the game.
  • Description windows. Almost everything has a description window now, either normally displayed on the screen (as it is when you pick a class) or as a separate window you can bring up by pressing (A) or (X) (as it is when you're picking feats). I've also updated the main menu to use these when displaying feats or skills.

    This gets around a problem I've been having of wanting to have fairly long descriptions of things but not having any screen-space to display it in most menus, due to RPG Maker's tiny, eye-strain-o-vision screen resolution.



  • Racial feats. Now, in addition to changing your appearance, the race you select also modifies your starting stats, skills and feats. Each race gets some kind of stat bonus (usually +2 to two stats and -2 to a third) and starts with several feats (you can see Dwarves and Elves starting with Darkvision and Humans starting with Skilled in the above video).

    Classes now also gain various feats, such as monks starting with various bare-handed fighting feats and fighters starting with several Weapon and Armor proficiencies.

  • Feat Requirements are now displayed while you're picking feats from the tree, if you don't meet them. If you meet some of the requirements for a feat (say it has 5 requirements and you meet 3), it will only display the ones you're missing. This should make it much easier to see what's available, what you want to take and when you can take it.

And that completely wraps up character creation for now. As of today, you can create a full party of 5 characters, customize their appearance (race/gender/hair/eyes/portrait/etc.) and their stats (class/feats/skills/etc.) and jump into the game.

The game itself so far only has a working menu. I haven't gotten into any actual gameplay yet (maps, combat, etc.) because I want to make absolutely sure everything else is setup properly before I start with that. Pre-production and whatnot. Once that's all done, even having a little gameplay will make it feel like a proper, decent quality game.

I'm a fan of the Blizzard idea of polish-everything-as-you-go, rather than do-everything-sloppy-now-we-can-polish-later (I can't remember who it was that said this in an interview, but it was something along the lines of: "There is no later. Polish everything now. Do everything right the first time").

Anyways, next on my schedule:

  • Add a world map to the menu. When I get to actually making the game maps, you'll be able to use it for fast-travel from any outdoors (non-dungeon) area.
  • A simple Party HUD: something that displays everybody's portraits and HP bars as you're walking around the game. Once I get around to implementing combat, it will all happen on the actual game maps themselves instead of going to a separate battle scene, so knowing your party status at all times (without having to open menus) will be useful.
  • Autosaves and Quicksaves
  • Quests, and a quest menu
  • Minimaps
  • Unique items and equipment. I'll probably be using a modified version of Tsukihime's Inventory System for this.
  • Crafting. This will be fairly simple. I liked the crafting in Temple of Elemental Evil, where you don't really need ingredients to craft anything; you only need the appropriate feat, meet a level requirement and pay some gold. It's pretty straightforward and shouldn't be too hard to implement once I have items working correctly.



Saturday, June 16, 2012

Feat Trees

So it turns out that making what is basically a skill tree made of dozens and dozens of skills isn't exactly easy. It's not really hard either but it takes a bit of planning. Like...more than I had done so far. After spending about 10 minutes  in the database manually assigning positions on the tree to various skills, it became pretty obvious that doing things this way wasn't going to work.


So I decided it'd be easier to make a full mock-up of the whole thing first, as close to scale (in terms of things being roughly in the right position relative to each other) as possible. I could worry about what that meant in terms of actual coordinates inside the window later.

A few minutes of googling turned up this site called lucidchart.com. It's apparently an online flow-chart designer, and it actually works pretty well. It was certainly a lot more pleasant to deal with than Microsoft's Visio, which I had used the previous times I had to do something like this. After a couple hours of messing around with it and cross-referencing my game's database and the D&D SRD wiki, I came up with this:


They're ordered roughly based on what level you'd have access to them. Low-level feats at the top, high-level epic feats near the bottom. Beyond that, I divided feats into categories; these are just the ones that I put under "Combat". It's amazing how something this simple gives you a much better idea of how a menu should actually look like. Once I had that, on to actually putting it in the game!

Before that, though, I just found out, completely by accident, that UTF-8 happens to have characters for drawing things. And I just happen to be working on drawing the links between feats inside the feat selection window when this happened. And it turns out that some of the characters are shaped exactly like the icons I wanted to use to display the links in the tree.

So, being the incredibly clever programmer that I am, I came up with this:


Screw figuring out positions for things, I'll just draw all the links (with text) and let the feat window code figure it out. I don't know why, but I find it kind of hilarious that this actually works. After messing around with the icons for a bit so they all line up when you draw them, the feat window now looks like this:


I had to copy/paste a few screenshots to get that (the actual window only displays about a third of that, and you can scroll up or down to see the rest), but you get the idea. I still have to give them proper icons and everything, but it's looking pretty good so far.

Friday, June 15, 2012

Feat Selection!

So I've just recently finished the visual aspects of character creation. You can see a video demo of it here:


With that done, I started (and spent most of the last three days working on) the other part of character creation. Stats, skills, classes...you know, the important stuff. The game part of the game.

Given that I already had the level-up process working for classes, attributes and skills, (yes, I implemented leveling up before character creation and yes, that is completely backwards; I'm weird like that) this was actually fairly quick and easy. Only took about a day's worth of work and I already had everything up and running.

Then came the hard part of putting work into the things I hadn't actually done any of yet. A few weeks ago I had a pretty awesome idea on how to handle the feat selection menu, but I never quite had the time to get to it then, since there were more important things to finish first. Well, I've finished those now, so I took a crack at it.

The main idea is: if you've ever played a D&D based game (like, say, Neverwinter Nights), you know that one of the things you pick every few levels is feats. If you, like me, played the game before ever playing pen-and-paper D&D, you've probably had the experience of being completely fucking lost in the feat screen.

If this all sounds like greek to you, feats are essentially special abilities your character earns ever few levels (every 3 for most characters, some classes get additional ones every few levels). They're all binary things: you either have them or you don't, there's no "levels" of them. Some of them are active, some are passive, some have nothing to do with combat. You could think of them as RPG Maker's Skills, but a little more generic.

See, the problem with them is there's fucking hundreds of these things. When you first create a level 1 Fighter   in Neverwinter Nights 2, you get to pick 2 of these (or 3 if you're a Human). The game gives you an enormous shopping list of every damn feat in the game that you qualify for (which even at level 1 is in the order of several dozen) and it's up to you to pick 3. And that's pretty much all the information you get. Hopefully you don't pick something useless that will screw you over for the rest of the game. Good luck!



That's always struck me as an awful way of implementing that. Even now, when I'm more familiar with D&D rules, I still have to double check rulebooks (or, more often, online D&D wikis) to make sure I'm picking things in the correct order and won't screw up and miss a pre-requirement for a feat I'll want to have like 6 levels from now.

So I started thinking: why doesn't this happen in other games? Well, usually you don't have that many choices, but in some games you do. You never feel lost like that when you play Final Fantasy XII or Diablo II though. This is because of how the implement their UI.


The main thing NWN2 is missing is that it requires you to actually know more than you can possibly be expected to know to make a proper decision. There's no way for you to look at that feat screen and know things like "Is this a pre-requisite for a better feat that I can't pick right now?" or "Can I just see the spellcasting feats? I don't really care about all these melee combat ones".

So I came up with a different way of displaying what feats you can select from. It'll look something like a mix between Diablo II's skill trees and Final Fantasy X's sphere grid.



The main point of it will be to display everything you can have, even if you don't qualify for it just yet (so you can have an idea of what to invest in and what might pay off to have down the road), and to divide them all into categories, so you don't feel as overwhelmed by the amount of them and you can easily find feats of a particular type.

That's what I've spent most of the last couple of days working on. Turns out it's a little bit trickier to implement than I expected, but I'm still making progress. With any luck I'll have a working first version of it done in a few days. This is what the menu looks like right now:








It's kind of hard to tell right now, since I haven't actually added very many of them (or drawn any of the connections between them), but the inside of that menu (the part with all the icons) is basically a giant grid. The orange tabs at the top are the categories and the icons are the feats. Hovering the cursor over one shows that tooltip with a feat's name on it. Related feats (i.e.: Power Attack -> Cleave -> Great Cleave) will have lines connecting them (like a skill tree).

Anyway, it'll make more sense when it's done. I'll probably post a video of it when it's all working.