ItemProperties And Random Materials

In the latest revision there are no limits to what any item can be made of. If there were swords there is a chance they could be made of grass. In the case of the current version, I've run into grass made of wood. This means it h as the burning properties of wood, but it's actually the grass item. This led to some confusing scenarios while debugging, but then I realized I hadn't implemented constraints yet.

Items now have ItemProperties which are kept in the Item class. These properties will include burnable, weapon, armor, shield, etc and can contain any combination. For now I only have burnable implemented.

While I have no real playable version yet, it is still possible to build the source and test it yourself. There's not much point in me compiling on Linux, archiving, and uploading a file that doesn't really show much except some funny fire mechanics and grass made of wood or leaves and walls/floors made of grass.

Shifting focus to features that make gameplay possible may be a good idea.

Edit:
Also, changes are currently being made in the /rewrite directory.

Platform Change And Other Random Notes

I'm primarily developing on a Windows Vista system now rather than Ubuntu. This means that my primary focus will be on Windows, but Ubuntu is available inside a virtual box easily enough. I should still be able to provide Linux builds.

Towns - I plan on making multiple towns with different populations, industries, and etc depending on geographic location. However, for the sake of early simplicity (and I haven't wrote up world generation yet), towns will have items that come from every location. In a short while I'll write constraints for areas on which materials can be found.

NPCs - I want the NPCs in Stone and Steel to have some flavor. I'll have a basic scheduling system for the AI to hunt/fish, eat, sleep, and whatever else their daily lives may require. I think I'll write the schedule instructions in a moddable file, but hardcode to whom the schedule is given. That way villages don't end up with 100% butchers and no hunters, for example. As for conversations, there's not an easy way to make things not generic in a completely random world. I'll be trying to make every topic discuss-able though.

Raids - Raids on towns would be a neat feature. Raids would be composed of creatures in nearby environs that are allied together, or at least not enemies, and enemies with the town. A basic faction system will be in place very soon, but it won't do much good, other than determining enemies to the player, until neat features like this are implemented.

Constrained Random Generation - As much as I want the game to be completely random, there would be some things that are just out of place for the environment. I'll be using some sort of constraint system when generating items for an area to keep a strong sense of setting and structure.

As always, feel free to comment/critique the ideas. My current focus is on towns and NPC interaction. This may shift back towards combat soon enough. Also, I'm adding a TODO page for this blog.

Fire

Stone and Steel now has burnable objects and fire! I'll be adding a file loader soon so that burnable items may be easily added instead of coding it in. Fire spreads, but doesn't really do much other than that. You can't burn down buildings or anything fun yet, and it needs a bit of tweaking. Everything starts somewhere, I suppose. The fire was more of a test for the new ETileType usage, but I'll be keeping it in since I like it so much.

Town Generation

So far the rewrite has gone well. I've even added a few things such as the background for town generation and openable items. These could be implemented better, but they do the job for now. Most of the code is nicer now though; it's much less difficult to fix things.

A screenshot of a randomly generated town.

My priority list has changed a bit, and I'm shifting away from a demo release soon. I'm currently more interested in working on the generation of everything, so I'm taking advantage of it and getting things done.

TODO:
- Add multi-room buildings to towns.
- Add furniture for dungeons and towns
- Add inhabitants to towns
- Refine dungeon and town generation
- Design some sort of history/general lore than can be procedurally generated much later and used in the game now

Playable Demo Goals

I've been thinking on my goals for the demo (for those who don't like to build from source). I'm definitely aiming for the following features:

• Body/blood injury system. No HP or anything of that nature
• Proper dungeon generation with zones for placing certain types of random creatures
• Basic kobold AI behaviors
• Working skill system
• Hunger/thirst system

There are a few other features I'd LIKE to have, such as a magic system and conversations. Fighting isn't the only way, after all.

The storyline to the demo is simple. Stop the kobolds from attacking a local town by any means necessary. The player will start in the dungeon after a short prompt and very limited inventory selection.

Rewrite

I'm going ahead and rewriting a lot of the code now that I have a clear design. I've actually managed to fix a couple of hackish solutions I had implemented before and eliminated some useless classes (DungeonFloor for example), but I've also created a bug in the cellular automata generation algorithm. I'm just not getting the same kind of results for some reason. I believe it may have to do with the neighbor cell checking.

In other news, I plan to change the game area around a bit. Since HP/MP won't exist sooner than later, I've removed the player info panel. To access the view for your injuries/etc the key will be 'c'. I'll go more in depth about this soon.

I'm nearly done with the rewrite though, and I'm already liking the way it works a lot better. It's similar in a lot of ways, but many things are just done right this time.

Let's Talk Combat

The current vision I'm having for combat in Stone and Steel is a simple EVade, BLock, and ARmor system. EV is the characters chance to outright dodge any damage. BL is the characters chance to block a percentage of damage, based on shield size, while reducing EV. AR is the characters damage absorption.

The chance to hit a target will be calculated by a 1D100 roll. For instance, if the target has an EV/BL of 20/10. Their chance to evade/block is %30. If the roll is 1-20, the target evades. If the roll is 21-30, the target blocks. Else, the target takes the damage and AR absorption is used. If the damage caused was 10 and the AR was 10, 10% of 10 is 1. 9 damage would go through.

In the future, whenever I implement body parts, random chance (and an aim skill) will determine what body part is hit by an attack. Armor coverage over that body part will prevent some or all damage done to that part. I plan for injuries to be a complex feature, but that's for another time.

Overview:

• EVasion is the chance for the character to outright avoid being hit.
• BLock is the chance for the character to block an attack, reducing the damage greatly or completely depending on shield size, and reducing EV value.
• Armor (items) will reduce the EV value, but add AR value. AR value is the percent of damage that is absorbed.

This sort of system will probably take a lot of balancing and testing, but it should prove to be reliable. As always, please voice your thoughts/opinions!