Stu's Rusty Bucket

Thursday, August 21, 2008

Skills again

Been thinking more about skills lately. I had only 1 attribute, speed, this is used to govern combat ordering.

I’ve been tweaking up some additional things, going to move speed out and create some general skills, something along the lines of;

- physical fatigue
- mental fatigue

All will be 100% based, rather than skill level based, and will probably fluctuate wildly throughout the game. This will impact things like how susceptible to poison the player is etc, ability to cast spells. Beginning players will start out something like 50% or 60%. Advancing physical skills will increase your base physical fatigue, so to learning other things will train the mental aspect. Some spells will require a certain skill level as well as a certain mental level.

Ive decided, the order of combat shall be randomised. Everyone will be put in the list and picked to go randomly.

If in testing that doesn’t pan out very well, I may just end up with a fast/normal/slow designation for every monster (PC’s will be normal) and randomly pick from the fast bucket until empty, then normal bucket then slow bucket etc.

For some reason, I keep getting stuck opon this order of combat thing, when it shouldnt be such a big deal, but I keep wanting to factor in a speed variable or something somewhere.

The skill list has been closed out, I’m finally happy with the result. All weapon types begat a certain skill. Swords require a sword skill, Hammer requires hammer, mace for mace etc etc etc. It was a long skill list. The more I thought about it, the more apparent that it was fairly useless. All the weapons were much the same but changed only in name. This first game is not about trying to add in the complexity of a roguelike which gets years of playing and balancing.

So, to that order I knocked back the skill list to something I had originally but later scrapped,

Weapons now fall into one of two skills
- Melee combat (for all swords, axes, maces etc)
- Ranged combat (for all bows, slings, javelins, darts, stars, meteor hammers, three sectional staff, manriki, etc)

The only downside is that it categorises long distance ranged weapons (bow) with short distance ranged weapons (three sectional staff).

Some weapons just don’t categorise very well, like a spear, its long range but also short range. A hand axe is a melee weapon, but can be thrown..

There are also base line weapons that don’t require any skill (knife, sling etc) giving every character something to start with.

Wednesday, August 13, 2008

Items data

Managed to do some work on Fishguts last night, after a long hiatus.

I’ve had a spreadsheet with item info in it for ages, and occasionally I will add some new stuff or tweak their stats.

Well, after much procrastination I broke open the Open Office Basic and wrote an export.

Ugh, what would have taken 5 minutes in Excel’s VBA took ages in OOBasic. OOB is a real nightmare. The differences are beyond night and day. I dont think I have anything good to say about the OOB implementation.

At any rate, I now have my items exporting correctly, its about 95% done and I need to tweak it a bit since right now it does not export any special fields (eg: +2 vs undead).

Its kinda nice to all of a sudden see items in the shop with correct pricing and such rather than everything costing 1gp and only basic test items present.

It has also forced me to solidify my skill system a bit, now with specific item skills. I did add some new stuff on a whim I had not previously intended to add (lol feature creep) but its a new weapon class mostly intended for thieves and their ilk (a throwing weapons skill)

Thursday, July 31, 2008

Inventory Management changes

I had a bit of a inventory brainfart today.

I have realised, with a game that has such tactical combat as I am going to have, I need to drop the unified inventory management system and instill a separate inventory for each character.
Think, character A on one side of the battle field swaps his sword for a bow, character B on the _other_ side of the field say 90 squares over, swaps his mace for character As sword, so yeah a unified inventory is great when you are constantly in party mode, but when characters are split up across the map, it fails somewhere (and I’m not talking the breaking of the simulation, this is after all a fantasy crpg with magic and such).

Lets think things over.

1 - We have tactical combat that situations will call for changing weapons etc in combat
2 - You may run out of arrows and need to change weapons
3 - Wear and Tear factor into gear
4 - Different gear can only be used with certain skills
5 - The need to tote different gear around because of 4

Inventory management is a real bear in any game, there is no right/easy way to do it, I don’t much like the Diablo method, or inventory slots, only inventory slots are the easiest to implement.

Yes one of the things is this game is about killing your opponents, scavenging the loot, finding better weapons etc and unloading the junk.

There is two things to consider;

1 - Shop management, buying weapons on a per character basis.
2 - Inter Character inventory management.

My take on #1 is that you enter the shop, choose to buy something and buy it. Once you have bought it, the game should then ask you whom to give it to.
As for #2, that is a bit harder. I was thinking a split screen system. Up/Down scrolls up and down the gear in character A, button press moves it to the other side. Press left/right to switch between the two characters etc. That lets you easily trade gear between the two. This from a “Trade Gear” option in the main menu.  At the top of the screen above the gear list will be the character names, scrolling up highights the character name letting you pick another character to trade to.

I need to mock it up and test it and see how feasible it is.

Sunday, June 01, 2008

Combat is back

Got serious on Fishguts this weekend. I gutted my combat engine, ripped all my sprites out and each monster has its own file now, so I am not trying to shoehorn them all into the base combat sprite sheet (that is reserved for magic sprites, missile weapon sprites etc, targeting box, stonned overlay, explosion overlay, grass tiles, wall sets etc etc etc).

Ive also rewritten my cellular automata generator, this makes better use of my templates than the previous version.

Wednesday, May 28, 2008

The Economy and Wear and Tear

I was reading a great article on Single Player Economies at moogle.net and it made me bust out my old spreadsheet and touch it up.

Richard made some good points in the article and its hard not to think of all the classic RPG’s I’ve played and how they did the economy… I think it was a consensus that they all did id badly. Remember Pool of Radiance and that they forced copper, silver, electrum, gold and platinum on you.. oh and jewelery and gems. Thats seven different types, and everything but gold or platinum (since it was worth more than gold) was useless. Worse, it all counted as weight that reduced your movement points so why would anyone carry large amounts of copper around?

I don’t even remember any use in the game for copper, silver or electrum. What shop made you pay in electrum?

How important will shopping and the economy be to my game?
At what point in the game does it go from being a struggle to buy basic items to not even needing/wanting to go to the shop ever again?

I guess its a bell curve that the price of gold rides opon or a straight line going continually upward. One of my aims is to make money still valuable right up to the end game.

Towns will all offer different prices for whatever goods they sell but they all sell similar stuff (but some shops only sell certain things you cant find elsewhere!).

One of my driving economic factors in the game was an early decision to make gold scarce.

• Gold drops will be limited
• Eliminate or limit grinding / farming

By having monsters drop a tonne of useless junk (long swords, leather armour) it encourages farming items to sell (which would still yield litte return due to inventory capacity), but by not dropping you miss out on things (i remember about the only thing I’d loot from combat drops in Gold Box games was arrows if I was low).

One thought I had for combat loot is to not drop items lower ranked than what the player has, eg: if the player has a long sword, drop put any short swords into the loot pile, unless it had some special flag (eg: +1 bonus vs trolls or something), and never drop more than number of characters in the party -1 of any item, so when fighting that hoard of orcs in Sokol Keep and being rewarded with 1,000 short swords, we would only drop 3 short swords for a 4 character party.

The disproportion of loot vs enemies can always be explained away with a message like “After looking over all the loot this is the best of what they had” or something similar.

To help drive my economy, I’m going to borrow the ‘wear and tear’ factor for arms and armour from Magic Candle. This will drive players to either repair items or replace them, giving more usage to gold or trying new and different items out. If you want to keep using that named “Flail ‘Ghost Smasher’ +2 vs undead” all through the game, you will have to look after it.

I was thinking the basic mechanics for the wear and tear function will be,

arms : each successful attack (blocked or not) will reduce by 1
armour :  each blocked attack of less than its Armour Value, reduce by 1, each attack over its armour rating (where player takes damage), reduce by 2.

Your standard Long Sword might have 20 W+T points fresh out of the shop. Each repair in the shop will return it to its max - 1. So you could repair it the first time to 20 points. The second repair will give you 19 points, the third 18 etc.
Better made/graded weapons and armour will have higher W+T maximums. Armour would have more, a standard shield may have 40, a wooden shield may have 15…

This gets us into the grading system (crude, basic, well made, exceptional, master crafted).

This also opens the door for extra NPC’s in towns and castles, as it allows me to place Master Craftsmen in certain places to do weapon upgrades or create you special items.

Wear and Tear will also affect wizard staves and such. Each time you recharge that staff or wand you will incur W+T and incur one less spell. Custom wand charging may only last for as many spells are chaged in that wand (one offs!).

Its easy to put things into the spreadsheet and check the bell curves, but playtesting will be the big revealer of how well it all scales.

I need to go off and play with the spreadsheet some more…

Tuesday, May 06, 2008

Quest Journals

In between drawing some arms and legs (see previous post), Ive been doing some testing on the PSP. Its amazing the little things that show up on there that don’t on the PC. (Porting is not an exact science). I found a couple of really stupid errors, obvious things that really only manifest on the PSP because of how its control pad reacts. Auto repeat is not good in menus, dialogues and quest journals).

Speaking of quest journals, my roguelike has one and I’m thinking of implementing it to augment the current quest journal, only not as verbose as my roguelike.

Right now the quest journal just shows given but not completed quests which you can page through and then completed quests. Each screen has the option to quit out or go to next item. I need to change it to use ‘X’ to quit out or directional pad to scroll through the items instead of buttons to page through…

Thats the basic quest journal, but I want to add something like a game notes. Not something the player can edit but something the game tracks and shows you, example;

On 4th of Foo, year 1203 The Party defeated foobar the great
On 8th of Bar, year 1249 Pinky was turned to stone
On 8th of Bar, year 1249 Foozle died from poisoning
On 30th of Zot, year 1253 Baz was recruited to the party
On 30th of Zot, year 1255 The party accepted the quest to find the hold grail
On 24th of Bar, year 1376 The party entered a moongate

Now the roguelike is more verbose (detailing on move X you did Y etc), but we dont need that kind of granularity. I think the journal notes would be recording bigger events. Not every combat the party undertook but used more as a memoir type thing and using a book type interface drawn with good old pale yellowing paper.

mmm… if I should be able to adapt my CNC code…

mmmm Thinking some more I don’t know if it would really offer anything up to the game. It makes sense in the roguelike but this kind of journal, I dont know for a traditional CRPG....

Think I’ll stick to the quest journal.

Friday, May 02, 2008

The Combat Front

Not a lot of updates on the Fishguts front. Minor minor things really.

I’m going to split out all the combat sprites into their own sprite sheets rather than bung them all onto one large sheet. Its a minimal help for memory consumption and means I can make several versions of the same sprite and not feel guilty about having them all in memory in the one sprite sheet.

I’m still debating (though 95% sold on the below idea) paperdolling to a limited extent, only because the player will always be a humanoid size (so no need to account for dwarf / ogre sizes in paper dolling) .

1 - Need only draw a couple of same size icons
2 - Draw a couple of weapons.

Each sprite will consist of a couple of primary colours (chest colour, arm, leg, boots, hat etc) that the player can cycle through to select.

Once chosen, this sprite will be composed as a flat bitmap and saved as a file on disk, so I don’t have to recompose it each time we go into combat

Lets think it over a bit more.

Players icon is composed of;

1 - Ready/Guard sprite
2 - Attack sprite

That would consist of;

1 - head (bald, hat, short hair, long hair)
2 - torso
3 - arm overlay (see below)
4 - legs
5 - boots

Placement must accommodate any one of

1 - One hand weapon only
2 - One hand weapon and shield
3 - Two handed weapon
4 - Bow
5 - Staff
6 - Nothing

Now right away I can see that a two handed sword selection doesnt mesh with anything else so separate arm overlays will be required…

Each item could have a one or two colour selection.. lets make it a one colour selection, using the ‘bright’ colours and I can map in the second colour for shadow/detail as being its ‘dark’ alternate.
(Those that remember the old ANSI colours or 16 colour paint programs will know what I mean by this).

Looking over this I have immediately made things more complex than I intended, but I think its a good complexity than forcing the player to always have a preset icon…

Now, in an ideal world, and which I may still implement, is have the player choose his primary colours for torso/arms/legs/boots/head and at the start of combat dynamically create the sprite using whatever selected weapon is on hand. That would require recomposition when changing weapons mid combat… that shouldnt be too bad since combat is turn based and not realtime…

Time to get back to work-work and stop thinking game development.

Sunday, April 20, 2008

Minor Updates

Honestly, I’m not doing a lot of work on fishguts lately. Been mostly messing with my language/compiler and my roguelike.

I did do some work on cleaning up my quest interface. I split it out into three files, one is just a set of constants, one a set of descriptions and such and the third is the basic routines. This way I can use my quest functions and just include the constants for things that dont requires the mss of loaded text for the quest descriptions.

Monday, March 31, 2008

Using Skills

So I know what my frame limiter was… I had sped time up to test some time triggers, which in essence converted it from 1000 ticks a second to 250. Hence the dropping by 1/4… Putting this back to 1000 ticks brought me back to 16/17 frames a second…

I double tasked the use option, so now when using an item you can toggle to using a skill! Now I can hunt in forests for food.

When using the hunting skill, it scans the tiles around the player, different tiles give different weights to what game can be found. Forests are best, then woodland then grassland. Each tile type has a multiplier, and a bonus is applied if your enclosed in all forest. The scan is a 49 tile block (3x3 around the player). This is calculated into a chance of finding game, making that chance then applies your hunting skill to see if you actually brought down and bagged that game. Passing that, gives a random chance for game type, the rarest gives the most meat, the most common, the least meat, (There are only 3 types of game).

Without building big, what I would have liked to implement would be a reference underneath so you couldn’t hunt more than once in a set area without reducing the amount of game there. IE you couldn’t farm a set of tiles indefinitely without exhausting them, and over time they would replenish… but thats not code I am willing to spend on something I’m trying hard not to bloat unnecessarily…

Monday, March 24, 2008

Hacking side effects

I was hacking on a bug last night when I kept getting some odd behaviour in my map code… Turns out in my coding spree last night I fixed a very very old bug that I had coded a workaround for a very long time ago, and in fixing the root cause broke the work around…

So tonight, depending on time, I need to do some cleanup to remove said workaround. yay!

Looking at the solution, makes me wonder why I didn’t do it right from the beginning.. At least it ts properly fixed now.

I need to address a big bottleneck somewhere. I am currently getting about 4 frames per second.. which is horrendously poor and I cant quite see why. I ran the profiler but didn’t really see anything… humm..

I have a suspicion, based on messing around with the intro code… will have to branch the code and test this week.

Thursday, March 20, 2008

Resizing windows and cleaning up the house

I’ve spread my self around last night, doing minor work on both CnC and Fishguts.

In CnC I built the game to resize the SDL window, and it works quite well, I’m very surprised, and it only took about 3 lines of C code to make it work. One suckage thing is that SDL clears the buffer so if you resize and hold the mouse down you get a black window until the game redraws the window, but you dont get that message until after you release the mouse button…

In Fishguts news, I’ve been tidying up my constants, the game uses a lot of constants in the C code and int he Lua code, and basically I have duplicate on the Lua side. I spent last night cleaning a lot up by having them set by the C code when a new Lua State is created, this stops me having to load the same constants in at the top of a script in an include file… so that is pretty nice.

Joy dislocated her shoulder so I’ve been doing all the baby caring stuff on my own lately which has killed any productivity but thats ok, its what marriage is about, taking care of each other. We are hoping its not a torn rotator cuff, so I might be doing only minor work on CnC + Fishguts for a few more weeks.

Monday, March 17, 2008

More on Combat maps

The internal debate right now is over combat maps.

1 - Do I blow up the existing map into the combat map, doing say every tile x3
2 - Do I load pre-made combat maps

Doing 1 is easy and hard at the same time.  It reveals the map layout (bad in caves/dungeons, but doesn’t really matter in towns or overland). The biggest downside is, it magnifies the map. The town maps use a simple tile scale. A door is 1 tile, etc. Suddenly you go into combat and the door is 3 tiles and a room might be 9x9 tiles. It might not sound bad but gives the wrong scale to the map. It sounds a lot more pedantic than it is.

One thing I remember doing in Pool of Radiance and Azure Bonds, when your in combat you can see the layout of the dungeon around you, which can be handy (you don’t see doors tho). The no door thing kinda bothered me, that suddenly in combat they all disappeared, but at the same time, I understood that this is what you get with the break between the map your playing and the combat.

Doing number 2 is really simple. I can pre-draw several combat maps, you know the plain grass combat map, the ship to shore type map, the cave map. This is the easiest method, but the downside is, what kind of maps do you have in towns? How do you represent the surroundings in the dungeon, if you have come down a crowded narrow corridor on all sides, you hit the combat map and its a nice open map with nothing like what you are really standing in..

I am leaning toward exploding the maps by 3 times right now. I may do some form of anti-aliasing so things are not so blocky in transitions.

That leaves randomness. Well except for town maps, all outdoor maps will have a random element, you know, downed tree’s, logs, rocks, etc. Dungeons and caves will have rocks, puddles and the like.

The dilemma there is putting a tree on the map… This is 2D, so you cant walk ‘behind’ the tree. The tree is in effect an obstacle. It wont obstruct view, and you can hide behind it, but should it obstruct missile weapons and magic? Magic is inherently.. magical by nature so you can explain that away. And hiding behind a rock should cover you from missile weapons…

There are a lot of edge cases. Its easy to see why in Ultima III, combat was just a plain grid of tiles, all grass or all floor or something, and your placed on one side, with one group of all-same enemies on the other. The smallest increase in complexity opens up such a can of worms.

Combat

Now that I finally have a working PSP backend playing nicely for the last week, I nutted out the flow and pseudo code for the combat engine. Looking at the top level flow of 25 lines is nice. It looks so much more do-able than the initial impression.

What is it really, but another abuse of the tile engine utilising different sized tiles (1x1, 1x2, 2x1, 2x2).

Some of the top level stuff is really basic (initialise the loot list to be empty), to the hard (determine placement of enemy parties on map)…

Some things are only as hard as you make them for youself. Right now I am still debating if I will ‘blow’ up and enlarge the current map into the combat map, or load a predefined map based on the square the party is standing on and the square the enemy is standing on (thus allowing ship to shore etc)…

I’ll keep mulling the top level and low level descriptions for a while so I can go in and implement it all at once and not have to do huge backtracks because I overlooked something silly or important

Tuesday, March 11, 2008

PSP working

OK I believe the PSP port is working as is meant to be right now Its kinda cool see’ing it on the PSP (since its a more mainstream device than the GP2X)… Still need a hacked firmware to run it so it will never be that awesome since Sony will never open it up… ohwell..

Back to working on the combat engine.......

Monday, March 10, 2008

Feel the PSP Love

I made a test PSP drop available and mentioned it on the qj.net forums.. I still have some quirks to work out with HOME key and doing a game exit… It seems I can always get one or the other to work as expected but not both together… sigh…

It playrs a lot better than last nights build so thats good!