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.

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.

I’m thinking of extending the time give before being kicked out of town, so that the player has more of a chance to see whats in the town than only being able to hit the supply shop first…

Things are slowly progressing nicely toward an 0.5 release

I can “trust” this on unix (my primary development system) but cant really trust it on win32 (everyone runs as administrator so… shrugs).

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.

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…

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.

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.

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