Had a brainstorm on the bike ride home yesterday about the actual implementation of skills. When the pool of skills is small I was thinking small, and each skill was a one-off, called during update as needed.
Thing is, that's not very manageable, not very intuitive. I'd end up with a bunch of these individual calls (one per skill) scattered all over the place, with implementations who knows where. There are already quite a few things going on in a creature's (or player's) turn, and every new added skill would just compound the problem.
So instead I made everything a skill (well, except movement although now that I think about it ... why not?); they're more like "actions" at this point, except some are passive, some active, and some reactive - this part will still take some thought. A creature (and the player) will get those skills loaded up through their XML (now in easy-to-parse, easy-to-tweak comma separated format) on creature generation, and then simply iterate through all of their skills, whatever they may be.
Currently, everyone has the ability 'regen' which is a passive and always happens (unless suppressed somehow), a few creatures have the ability 'throwWeapon', and some have 'summonSelf' which summons another creature of the same type to help. Some of these actions take a turn, some don't, so some will be "blockers" for other actions. What I'm still working on is a sort of weight as to which action a creature should take, for which I think the creature STATUS and STATS will be responsible for.
For example, let's say a creature has 'teleportSelf' and 'castFireball'. If I just give it a percentage chance to occur, the creature will always end up doing one more often than other. However, whether I want the critter to do one or the other depends on what state it's in! If it's wounded, it should probably teleport away; if it's close by it might want to attack in melee instead; and when it's far away, it should throw that fireball. I already have some rudimentary statuses in like ENGAGED, SEEKING_TARGET, SEEKING_ITEM but I suspect these will have to become more verbose. Still, by solidifying the skills into an actual system all of this will be much easier to do.
Oh yes, if anyone else searches for "using a string as function call in as3", this is the way to do it:
var myFunction:String = "castFireball";
I had no idea that was possible. It's tremendously useful for things like this, when you need to call functions that you don't necessarily know the names of.
Behold, the amazing debugging line of sight imagery :P
I've also started working on a special ability - summoning help. I *think* most of the code is done, but it is yet to be tested. On top of that, I think I introduced an infinite loop somewhere in the line of sight code - I started getting annoyed at the mess of X/Y vs tileX/tileY and began some work on it, but I suspect it's missing a conversion somewhere. Well, it *was* very high on the post-MVP priority list, so maybe I'll move it up to happen sooner. Might be easier at this point than reverting tonight's work, hah.
Hmm, maybe I should start tagging with things like "tech", "graphics", "AI" ... but I'd probably just get lost in the tag cloud. Welp, I'll try it. This one is "structure", short for dungeon structure I suppose. I'd use architecture, but in software development that can mean quite a few things.
Way back when I had the idea of leveled critters, their level span would be quite large as they would grow with the player. Fortunately I threw that idea out, and so creatures will have a smaller level span - I'll just have more features. I think this will differentiate the levels a bit; more creature variety will show the player that their environment is changing. Goblins to goblin squads, wild dogs to wolves, kobolds to trolls and so on. At some point minibosses and such will start showing up, possibly leading squads - this *is* a defensive dungeon after all.
In any case, the code for this is now done and minimally tested (like most game features, ha!). It will take actual playtesting, further creature development, and probably a substantial amount of numbers tweaking to make it perfect, but "functioning" is good. I might add a few more creature variants today for starters.
Next up, that ranged combat. I'll have an *exciting* path-tracing screenshot later today.
Attempt at buying a house + crazy baby = not much time to code. It's almost to the point where I'm a little worried that i'll forget what I was doing last. :/
In the meantime I'm designing a combat system on pen and paper. Well, in notepad in my email anyway, for portability. It's going to be some sort of blend of dice rolls that are affected by your stats and skills and item stats, I think. I'm going to handle evasion with a toHit roll that will be modified by your stats, skills, items and effects (like say enchantments or potions) and damage with a weapon range that you will roll on. If your roll falls in a certain range, you'll do x% of the total possible damage, with small modifiers added via your skills and stats.
At first you'll gain a couple of stat points faster, so they'll have a larger effect, but in the later game the stat gain requirements will increase exponentially and you'll be focusing your effort on improving your skills (through usage and possibly reading tomes, or finding a trainer), finding better items, and obtaining enchantments and such. I think it'll work, but it's all very initial. I haven't even run any paper scenarios yet, so it's all very tentative for now. Still, brainstorming (as long as you put something down) is better than no progress at all.
I found this in the archive, thought I'd throw it up here see how it compares ... witness the early blood splotches and NPCs/PCs. :) You can also see "iron chain helmet", which is an item scheme that no longer exists, and the awesome creeper background. Those dungeon tiles will come back though; the forest is just the start of the game.
The stairs (i.e. squiggly lines) actually work now - that is, I put in the code that detects whether you're standing on a real stair tile or not. Sure adds a bit of gameness (gamity? gamection?) when you can't just fly through the levels ...
Also not seen in this shot is the path tracing that's still a little buggy. Hopefully will wrap that up this week, which will enable ranged combat to happen.
Following the doing away with leveled creatures, I'm working on some very initial design docs for combat and player development. While this stuff is very far off yet, I might as well be thinking of the ramifications now while the codebase is still relatively simple. For example, since the NPCs won't have levels nor a ton of skills - and PCs won't have anything as simple as Special Attack 1 or Special Attack 2, not to mention PCs won't award XP for getting killed, ha! - I'm going to break out their XML objects away from PCs. Things like that. Better now than later.
And here's an image; there should be more of these since I just came up with a way to easily paste URLs and have them tagged as images. Yay!
After some consultation with the snarkmaster (a serious CodeSquares contributor), I have decided to do away with leveled creatures. Originally I was thinking about some sort of auto-leveling a la Oblivion (except one that worked better) where creatures would gain more skills, have higher chance of casting some spells or using abilities, and have better gear. There are a few problems with that though.
First, nobody likes autoleveling. It negates a lot of the sense of accomplishment when you gain a level when everything else does too. Second, it's hard to do well - Dead Island does ok, but that negation of accomplishment is certainly a factor. Third, in a roguelike where the numbers of enemies can be potentially huge, leveling negates the sort of instant recognition that a tile-based game should have - is that a level 1 goblin that I will swat, or a level 5 goblin that will just destroy me AND my army? That is something I would want to be instant, and there's only so much you can do in 32x32 pixels - but I could instead present a goblin champion as a different graphic, and the player will instantly see that it's different from the base goblin.
Another reason is technical; while I *could* create a system for equipment overlays (and this is in fact planned for the player, and at least weapon display for the creatures) and enhance it to show more "flair" on a stronger creature variant, I am fairly certain that I can't do as good of a job attempting programmatic tile variation as a hand drawn piece of tile art would.
So yeah, no leveling on creatures. There will be a standard progression of weak creatures near the start and stronger creatures towards the end, with creatures having an upper and lower limit of appearance. There may be a little stat randomization at some point, and definitely weapon randomization, but a creature type will always be that same creature type and behave consistently everywhere you see it. That just seems much more playable. This will all be in XML files for ease of tweaking, too.
I'm not sure which of those I'm most excited about, but probably the solidity override. It's not tested yet, but when it works properly it means that deformable terrain is possible, in true roguelike fashion.
Stairs are pretty simple now; all I added was the player position on ascending/descending - this part's still broken, actually, but I think it's just the usual tiles vs. real coordinates kerfluffle. I should really standardise this at some point soon.
Finally, Signals are an event framework. What this means is that instead of, when something happens, having to write functions that pass parameters around and around to all the things that are interested in them, I can just fire off a signal (event) and have all the interested parties be alerted and take action as appropriate. This just keeps code much cleaner and more intuitive.
The best example for this is exactly what I'm using it for, combat. Before signals, I'd have to call: creature hit; creature doing the hitting; splatter emitter; kill checker; noise propagation; terrain deformer; and maybe even more as I keep adding features. Each of those would have their own needs and data requests to keep track of, too.
With signals, I just say "a combat action happened" and everywhere I put a "listener" I add the appropriate action. Since it's a universal signal this also helps me figure out a universal set of data needed for the event - in this case I send along an event type (like say PHYSICAL_COMBAT or DIGGING or EXPLOSION) and the elemental type resulting from the action (PHYSICAL_HIT, FIRE EXPLOSION, ICE ERUPTION, etc). So far that seems to be all that's needed ...
I can't wait to add signals on signals :) Can you say possible chain reactions? I know I can ...
There are a couple of things that I wanted to address for some time, but I've been so head down in the mechanics (still am, armor and ranged combat remaining) that it got put off over and over.
First, I still don't have a concept of endgame, or deeper design than just keep-going-down-and-kill-things. While this is fine for plenty a roguelike, I always wanted to do a little bit more. The game was always intended as a hybrid roguelike and dungeon simulator (lite), it's just that the roguelike had to happen first so there was a foundation to build off of. A lot of things are created with that in mind - the randomized weaponry, randomized levels, randomized critters, flexible tiling system, the planned Events as an action trigger ... I'm sure I'm not looking far ahead enough and will have to do rewrites anywhere, but I'm trying to plan for many eventualities.
With that in mind, the game will eventually let you control and alter dungeon rooms to your liking. I have yet to decide what those will be, other than some basics such as Armory, Training Room, Baths (a clean monster is a happy monster!), Recruitment Center all of which will impact the number and equipment of friendlies on a level, and then luxury things like Alchemist, Weaponmaster, and of course a Dungeon Enhancements 'R Us so you can obtain traps and such. As I think of these things, some sort of design plan is crystallizing in my head for "endgame". See, the initial concept of you being a disgruntled dungeon inhabitant and turning on your creator/paymaster works only up until you get to him/her and take them out. But then what?
Well, I still have the core of heroes invading the dungeon and trying to do the task for you, so you have to deal with them as well. But once you get there, what would be the reason for the monsters to line up behind you, and for the dungeon to be secure? There wouldn't be - so you turn right around and go back with the wizard's (or warlord's, or mad scientist's) artifact (haven't decided what yet, how does this sound:), the Sceptre of Sealing, and make your dungeon the most secure, well-defended and most importantly - unionized and well-paying! - dungeon ever. Hmm, maybe the Sceptre of Fair Pay. At this point the monsters will be mostly neutral with only a few holdouts, you'll have more money so you can build more structures, and the influx of heroes (who have heard of the wizard's downfall and are running for the loot) will become a serious problem and teaming up with other monsters will become vital.
I AM MAKING ALL OF THIS UP AND IT IS FUN.
I think with this somewhat tongue in cheek design concept I have no choice but to outsource some snark for the game. I therefore welcome all comments in that vein - I could use monster, weapon and armor names and attributes, as well as catchphrases to display on the (nonexistent title screen). So far I got:
"Dungeon dwellers of the underworld, unite; you have nothing to lose but well, everything."
"Dungeon Contractors LLC; no dungeon too small, some wizards too tough."
"One day only - patented hero detectors. Only at Dungeon Enhancements 'R us!"
"A monster has appeared! Run/Fight/Talk/Swap stories?"
"A hero party has appeared; the paladin looks buff. Run/Run/Run/Run?"
I JUST MADE THESE UP ALSO (you might be able to tell). This is GAME DEV.