Back to Basics

Alchemy design has been taking up most of my project-time lately, even the limited number of ‘bases’ I’ve started with have led in a lot of interesting directions, but it all takes time to think through and write up.  I’ve only just started on essence combination, what I might have to do is pull everything back to just a couple of the most basic bases and implement the more complicated stuff later, or else it’s just going to take too long.

In fact, that’s probably what I’m going to do with most parts of the project, really reign it in, in terms of actual content.  From my original designs I’d already minimised to what I thought was a very, very basic level, but actually it was still fairly ‘full’.  And as I worked on various systems features that I liked kept creeping back in, or I’d think of something interesting and let that distract me.  Most commonly, it was the lack of design documentation that led to lack of focus, so I think the best thing to do at this point is go back to the design stage and do the ground work.  A game like this is too big and too complicated to just make up as you go along, and although I do have design notes of varying depth, one thing I never made and definitely should have is a unifying ‘map’ of sorts, a design document that describes the relationships between systems.  How everything locks into everything else.

So, my current goal is to create good, solid, workable design documents for each of the systems I have yet to complete, and a design map that shows how each system works with other systems.  After I have those, I can start working properly.

Algebraic!

Today I worked on the alchemy system (‘herbalism’ doesn’t seem appropriate now that a lot of the mixables aren’t herbs), making big spreadsheets to keep track of all the combinations and what-does-what–there are basically three things you can do to a ‘base’ (eg scavenger claws, silver fern leaves): Drying, Boiling and Grinding.  Drying requires a drying mat, little preparation time and expenditure of energy but you have to wait until the next game day to see the results.  Boiling takes time but little energy, and also firewood (and a pot).  Grinding varies depending on what you’re trying to grind, but usually takes both energy and time (although less time than boiling).  It requires a mortar and pestle.  Each base can produce various ‘essences’, depending on the actions taken.  Sometimes different actions will produce the same essence, but in  varying qualities and sometimes with a quality modifier.  Sometimes an action will destroy the base or have harmful results.

Once the player has some essences they can either combine them together, or attempt to make something with them by ‘finalising’.  Most essences have three possible ways to be finalised: The creation of an ointment or unguent (boil with oil and place into a jar), flasking (putting a liquid essence into a watertight container of some sort), or simply putting the essence into a pouch (only works with ‘dry’ essences like powders).

Currently there are around a dozen bases, of varying rarity, which can produce around three dozen essences between them.  I’ve only just started working on combinations, but there should be around a hundred different ‘results’ of alchemy.  Quite a lot of work, but I think it’ll be worth it.

The Return of The Kid

Phew.  Had a busy couple of weeks, that coupled with a little bit of burn out meant not much has been done on the game lately.  What I have done is mostly design-related, a little bit of content, and recently more coding on the combat system.  I think that’s what turned me off about the project for a while–too many hours sunk into one part of it.  However, it’s nearly done now, and I’m pretty sure nothing else is going to be as big as the combat system.  It’s my own fault for making it complex to begin with, I should have started simple and added features gradually.  On the other hand that would’ve meant a lot more work in the long run.  In any case, I’m almost at the point where I can move on to other things.

The other things in this case will probably be more content, especially in the town.  ‘Support’ for the monster drops, which will be the kind of things you’d expect monsters to drop (ie bits of themselves).  Some of these bits will be useful in ‘mixing’ for the alchemy/herbalism system, some will be ‘craftable’ into decorations or possibly weapons, and some will be edible.  So, for example, if you kill a blue scavenger you’re likely to get a handful of scavenger claws, some scavenger teeth, a blue scavenger hide, some scavenger meat and a blue scavenger tail.  The hide is craftable, as are the claws and teeth (which may also be ‘mixable’ with the proper preparations).  The meat is edible and the tail will be important later.  The player can sell all of the bits to various people (or, eventually, other players) or use them themselves.  At least, that’s the plan.  I might have a ‘trade’ system too–trade two raw blue scavenger hides for one treated one ready for crafting into armour, for example, rather than just sell them for money.  On the other hand money makes things simple.

Skill badges are another priority right now.  I’m still undecided about when they’re awarded–at the time you ‘earn’ them, or through some set location.  I’ll have to think about it some more, at the moment I’m leaning towards ‘when you earn them’.  Maybe with a little pop-up “You’ve earned the ‘Knifey-Knifer’ skill badge!”.  I think that’d be more satisfying.  It means more code in individual pages, though.

Not even a biscuit

Had a wee three-second panic this evening–went into the combat page to do some checking and editing and up pops the debug window with an array full of gibberish.  “Oh no!” says my brain.  “The database is corrupted!  I haven’t done a backup for days!”  Then things resolved themselves and I realised it was just my serialized array backup system doing what it’s supposed to (or at least what my half-finished code is telling it to do).  So, phew.  Actually, it was a good reminder that I needed to finish that, so I spent a few minutes finishing the ‘retrieve’ part of it and now it seems to be working well.  Serialized arrays really are very useful things indeed.

Aside from that, I’ve done fairly much bugger all on the project over the last few days, this mostly related to my coming into a couple of games that have occupied my attention pretty much completely (even as I write this I’m thinking about playing one in particular–Mirror’s Edge).  It seems the greatest threat to productivity on this game project is Other Games.  Which makes sense; if I have no new, compelling games to play then my mind naturally turns to creating a new, compelling game (and game-creation is as fun a game as any, even if the rules are a little difficult to understand at times).  If I have other games to play, then I’m not so concerned with creating my own game.  It’s pretty much the opposite reaction I have to other media; in particular reading a great book makes me want to write a great book.  It’s part of the inherent ‘difference’ of games, in that aside from an art-form (or, to be more specific, a medium) they’re also, well, games.  Games that are meant to be played and enjoyed (well, the good ones, anyway).

But anyway.  The things I have accomplished over the past few days, in the aggregate hour or so I’ve spent working on The Project, are the aforementioned save/restore system for combat, some minor typo corrections, the basic description of a new location, and a rather neat little system of ‘danger levels’ for different areas–green, blue, orange, red and another one that’s a secret.  This came about because I noticed navigation was a little confusing–because everything’s just a text link, and because your navigation options are limited to the areas directly accessible from your current location (ie you can’t ‘cut across’ locations), it can get a little messy.  So, now there’s a cute little coloured marker beside each navigation link, indicating the ‘danger level’ of that location.  Green is completely safe and ‘civilised’, by which I mean humans are living there and probably trying to sell things to each other.  Blue indicates an area that is free of monsters but not necessarily inhabited by humans.  Orange indicates an area that, while not exactly ‘dangerous’, could be considered ‘wilderness’.  Red indicates an area in which hostile monsters are known to live.  The secret danger level indicates something else that’ll become important eventually.  So, with this system in place things are much clearer and navigation easier–if you need to get back to ‘civilisation’, head for green, blue, orange, in that order of priority.

Anyway, the real point is that I need to summon up some discipline.  As much appeal as shaving off a few seconds from Chroma holds, I’m getting into bad productivity habits.  So, from now on, I’ll spend at least an hour a day working on The Project.  And if I don’t, absolutely no pudding for me.

Even so it’s fun

Spent the morning writing more combat code, functions to retrieve actions and check validity of actions and so forth.  Error-checking is taking up about half the time with this, but it’s important to have (if it wasn’t there then a player could potentially submit a fake ‘post’ and take any action they pleased, if they figured out the id for that action).  My extensive design notes have saved a lot of time–it’s always a lot faster when you know what you’re supposed to be coding–and helped avoid at least one rather sticky situation.  Especially for something like a combat system, it really is very important indeed to have it all worked out before you start coding, unless it’s a very, very basic one.  With mine there’s quite a bit of complexity so without design notes I would’ve gotten stuck at least half a dozen times already.  As it stands it’s been fairly straightforward, it just takes a lot of time to implement everything.  In any case, it’s up to ‘phase 4′ now, which means the player can encounter a monster (and everything gets generated and stored properly), the monster will perform a ‘pre-action’, the player is presented with a list of actions (sorted by the item or lack-of-item that enables said actions) and can choose one, then the code grabs all the relevant stats for that action and adds the stats for the item it’s performed with (and does something similar with the monster; rolls up a random action based on their pre-action, grabs the stats for the action and adds the monster’s stats to it) and puts it into a nice tidy little array, ready to work with.

Next is the actual ‘combat’ part of the combat system–hit and damage resolution.  This is where things might get a little messy, so I have to be extra-careful to make sure things progress cleanly and clearly.

Ho! Haha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!

Slowly but surely chipping away at the combat system.  Today I wrote the ‘backup’ and ‘restore’ functions for combat (so that even if the player closes their browser, when they log back in everything will be as it was), and wrote quite a nice little function that takes the action probabilities of each pre-action (stored like 9/30-7/10-8/60, to be read like ’30% chance of action_id 9, 10% chance of action_id 7 etc.) and explodes them out into an array, then rolls a hundred sided die then checks it against each probability to get the monster’s action for that combat round–it’s the reverse of how I’d normally do this, but because the number of possible actions is not set (ie there could be two, three, four or more possible actions for a given pre-action), it’s the best I came up with.  One flaw is that if the action probabilities don’t add up to 100 then the possibility of an infinite loop is created.  I could put some error-checking in for that, but it’s easier to just make sure my numbers are correct to begin with.

In any case, it’s working pretty much exactly as I want it to–the player is presented with the monster’s ‘pre-action’, and from that can try to predict what it’s going to do.  I’ve worked hard to make behaviour consistent–each monster has ‘tells’ that telegraph certain attacks.  Some of them are quite basic (aggressive pre-actions usually come before attacks), some more subtle (for certain monsters it’s the absence of a certain behaviour that telegraphs a particular action, for example).  All in all I think it’s a good, fun system and I’m quite proud of it–it kind of replicates the sort of combat system I enjoy the most in real-time action games (observe and react).

Possibly clear

Another lazy day, all I really accomplished was noting down some preliminary stats for the starting weapons and rewriting some dialogue.  Mostly I blame Patapon 2.  It’s a pretty good game, above average certainly but nothing spectacular, and yet it has this compelling quality … I find it very difficult to put down.

Anyway, in order to get back on track I need to write down what needs doing.  So, for next week:

To-Do:

• Finish up the weapons/armour market, to the point where players can buy weapons.  (Selling and repairing weapons can come later.)
• Expand weapon and armour ‘wear’ system and implement it.
• Continue coding the getCombatStats function, tieing in weapons and armour properly now that they’ve been implemented.
• Assuming this hasn’t led to something else that needs to be implemented, continue coding the combat system.

Keep wishing, and hoping, and thinking, and praying

Not much progress over the last few days, for a couple of reasons (busy with other things one day, a little bit consumed with Saru Saru DS another), but I have been doing a bit of research and design, and today I wrote quite a bit of content for the new market area–it’s quickly becoming one of my favourite areas in the game, with some fun NPCs–one in particular, an old soldier whose basic function is to give the player information about various weapons and damage types, quickly transformed from what was essentially an exposition device into probably my favourite ‘character’ in the game so far, with his old war stories and surprising pathos.  Another new NPC forms the basis of something I really want to do with this game–a character who starts young and naive and bright, and who players will gradually see grow and develop as the game progresses year by year.  Eventually having to let these characters die isn’t something I’m looking forward to, but it’s a part of things.

The more I work on this, the more the feeling grows in me–or rather, the question: “Why does nothing like this exist?”.  It’s not a terribly original idea, an online multiplayer game with a timeline, with characters (both PC and NPC) that age and a gameworld that grows and changes.  Perhaps more importantly, individual actions that contribute to community goals.  I’m sure people have had this idea–or one very similar–before me.  Maybe it’s that it seems too ambitious for a single amateur (or small group of  amateurs) to do, while being too … what’s the word … unviable maybe, as a commercial venture. Not that I’ve ever thought of it like that–never “This is an idea I could sell!”, rather “I’d really like to see something like this, I wonder if other people would, too?”.  Of course, web-based games need money to run and I don’t have a lot, so ideally I’d like to get enough in donations to keep the game running, but I’m never going to charge people to play–and you’ll never need to donate to play, either.  (With that said I do enjoy things like KoL’s Items-of-the-Month, but if I did implement something like that it would probably be mostly cosmetic or involve game mechanics or content that were fun and new rather than things that gave donators an advantage over non-donators.)  I don’t have any dreams or expectations of it being a huge success either–if it eventually becomes a fun distraction for, say, a thousand people I’d be more than happy.  Actually, I’d be happy if a dozen ‘regulars’ played and enjoyed it and everyone else in the world ignored it entirely, to be quite honest.  Just so that I had justification to continue working on it and to create new content (and update the old).

As well as that, as far as ambition goes, I’m very aware of not expecting too much or getting beyond myself … and yet the more I work on this project the less ambitious it seems–already a lot of features I’d noted down as being ‘pipe dreams’ or ‘completely unrealistic but fun to think about’ are seeming more and more achievable … web-programming isn’t nearly as difficult or scary as I thought it would be, vague worries I had near the start of the project about running out of ‘content ideas’ have proven to be completely unfounded (if anything I have too many ideas for content, and that’s before any kind of player input), and most of all it’s fun and satisfying to work on something like this–on every part of it, actually, be it research or design or coding or writing, it’s all fun in different ways.

In any case, for now, I’ll just keep working on it, doing a little at a time, until it’s in a playable state (well, technically it’s playable now, but you know what I mean).

It’s the little things

Another day spent chipping away at the combat system.  Today saw more content for the fields, more content for monsters, and the start of implementation for the weapon-action system.  Similar to the monster-attack system, each weapon can be linked to any number of possible attacks, so an iron knife, for example, might be used to stab, slash, perform a guarded slash or a fierce slash.  Aside from weapon actions there will also be basic actions–defend, dodge, hold back, switch weapons and so on, and then also combat skills (if any).

However, before going further with combat, I need to put a more robust equipping/unequipping system in, and probably a place to actually get weapons and armour, come to think of it.

Research, people always forget the research

Busy with other things and still a little sick today, so not all that much got done.  I continued work on the explore and combat pages, linking them together, and put together some pseudo-code for the progression of actions in combat.  I think before I progress further with the code I should work on some more combat content, the AI for monsters in the starting field, monster attacks, status effects and so forth.  That way any inadequacies in the way combat works will come out now rather than halfway through coding.  Already I’ve noticed that I’m going to need at least one more page (for retrieving the spoils of battle, I could put it in combat.php but that’s already going to be quite big).  Besides, I’ve been mostly just coding for the last while, it’s time to take a break and do something else.  When you’re doing everything yourself it’s quite important to balance things out, and for myself personally I get bored if I’m just doing the same thing for too long–part of the reason making a game appeals to me, there are so many different things to do.  Also, using PHP and MySQL to code for a almost entirely text-based browser game, there’s a fantastic speed to things–I can go from having the idea for a feature to designing it to implementing it to playing around with and testing it often in the space of a single day.

I found a couple of books recently that are serving as good research–one is the history of a small settlement in the South Island of New Zealand, complete with survey maps and biographies of the various families that made up the community, the other is a history of western contact with the Nelson region of New Zealand (my home region) from the first ships in around 1650 right up to the founding of the first township in 1842.  Just the dozen or so pages I’ve read already have given me a bunch of ideas–mostly impractical, but still.  In any case they’re helping to give me a better understanding of things.