Stu's Rusty Bucket

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!

Sunday, March 09, 2008

PSP Update

As an addendum to the previous entry today, I managed to play Fishguts on the PSP! Pretty sweet. Its only about 95% as I need to change some of the button handling.

Also the game doesn’t quit correctly, which is odd since all the callbacks are setup…

So anyway, it was a pretty cool feeling seeing it fire up on the PSP

Unfortunately you need a CFW (Custom Firmware) to play it…

PSP Code Base

I think this week will be spent bringing the PSP backend up to speed to where I can run Fishguts without any problems, or at least it should match GP2X functionality.

I’m hoping to just wrap SDL with psp function calls and a few callbacks for Sony’s kernel routines.

I dont think it will be too hard. and I readly have the toolchain built from the last attempt that I gave up on after I built the toolchain! Talk about getting nowhere.

Anyway, its time to start testing the actual PSP code, since the PSP technically has half the memory of the GP2X, eveo tho its mostly the same (since the top 32mb in the GP2X has other priorities, caching etc. and you need a mem hack to enable it, but since I dont...The GP2X is pushing the same memory limits as I’ll be pushing in the PSP....)

Friday, February 29, 2008

Minor things to fix

So minor things to fix up

* Seriously need to redraw my river. shallow water, sea tiles. They are definitely too much of a “placeholder” tile.
* Redraw my teleport gate tile
* Cave tiles need reworking
* Cleaned up Character creation menu (yeah that nasty red box)

I’ve also started work on a naming your character screen, which I was kind of against doing, since this means I need to write some kind of popup text entry widget which always suck on handhelds, and no, it wont have some kind of predictive input or T9 system, after all, its only going to be used to enter your characters name.  Right now I have a list of say 20 names and it randomly picks one for you when you start a new game.

Need to finish the oracle / pub shop code (relatively minor piece of work)

Even tho the item list is preset, now different towns have different markup prices across the board (basically a small percentage increase or decrease) over the preset price. This only affects the buy price, the resell price is based on the preset price, this stops people from buying things cheap in one town and selling them in another town that has a higher markup. The sell price will always be the same in every town but the buy price will fluctuate from town to town, but it wont change each time you enter (its not random). I certainly don’t need to model an entire economy with price vs goods fluctuations.

The only problem I am aware of right now is selling an item back to a shop that it doesn’t sell.. Example being, a backwater town might only sell some basic weaponry, and you come along and sell it and the Sword of Fargoal +2 that you brought two towns over.. They’ll pay you for it no problem, and then you go back into the buy option and its not there.... I could attach a list to the shop { item id, qty }… suddenly I don’t like the fact that when you come back 6 months of game time later the same item is in the inventory… wtf, does nobody in this village realise how kickbutt the Sword of Fargoal +2 is that they didn’t buy it already?? argh. Now I’m expecting too much of a simple game mechanic but I feel if you start to do something, you need to do it right and track all this kind of thing..

OK so I’m back where I started, you sell the Sword of Fargoal +2 to the shop.. and voila, its gone (just think, hey some other dude came and bought it right now or the shopkeeper wants it for himself!)…

Its unrealistic for shops to

A) Sell every item in the game of type X (weapon, armour)
B) Doesn’t sell every item in the game, but that list never changes
C) Doesn’t sell back the things you sold it
D) Doesn’t track the resale price like it tracks the original sell price
E) Not take VISA

I need to think on this some more.. It really bugs me what I sell doesn’t appear in the sale list

Wednesday, February 27, 2008

Fishguts Screenshots

Lots of work in progress pics behind the jump… (Different versions eg: pc/psp/gp2x/gp32 had different title screens. Here you can see the GP2X title screen)

PC = Fishguts Title Screen
GP2X = Marakesh (yes the spelling is correct here, its not Marrakesh)
GP32 = Zanzibar
PSP = Morocco
Pandora = Kampala

Right now the GP32 is defuct tho…

Thursday, February 21, 2008

Again with the small steps

Again, taking small steps I flushed out another castle map with surrounds. This map is kinda odd compared to the other maps as its a much larger map, previously I had made my indoor maps 96x96.. but this one I modeled some surrounds with it and its a 160x128 or 160x160.. Prior to this it was a map of green unfilled squares whose script contained nothing but an enter and exit events.

Maps Left to Draw
* 4 towns I think, need to check my notes.

Once thats done its down to populating them with the NPC’s and dialogue and tieing up all the plot points.

Still to do
There are still things that need to be worked on before I can no longer avoid working on the combat engine.

* Sailing / Riding (flying eagles of questron ii??)
* Lockpicking
* Stealing chests
* Mountain Climbing

But none of them are really code intensive.