Balance in all Things

Today I'd like to talk about my idea behind Rouge's game balance.

More specifically, how there won't be any.

Oh don't look at me like that. The game will be perfectly playable (you know, when I eventually start releasing the bloody thing), it's just that, beyond the first floor of the first dungeon, any challenge the player faces will be effectively self-imposed.

I'm basically taking the Fable approach to balance.

IDEA: take player to levelup screen only when player asks to go. If you want to play a low-level game, you won't need to not kill dudes.

Basically, I'm not going to try and balance Wizards with Warriors. A dude who can set shit on fire with his mind is probably going to fare better against the legions of Hell than Fightsy McSharpStick over there.

I'm not going to try to constantly challenge the player in a generally open-ended world of highly variable content. If the player wants challenge, they can make it happen on their own time.

IDEA: difficulty levels. Straight stat multiplication on enemies.

Basically I figure I provide 1: the sheer catharsis of murdering everyone who's ever looked at you crosseyed once you hit level three and 2: the capability to do crazy things to prove your 1337ness by beating the final boss on ExcessivelyHard mode as a level one thief, with nothing equipped.

Except if that second one is at all possible, then I have fucked up severely.

The point was to illustrate some of the crazy shit that's possible if you provide an open enough engine, where you can either level to a bjillion an curbstomp everything, or show your awesomeness by limiting yourself and still kicking ass; see also Final Fantasy Tactics.

Again, I'm not looking to make a hard roguelike. I'm not really even looking to make a roguelike. I'm looking to make a dicking-around-in engine that'll give me the giggles.

And maybe if it's easy enough, I'll be able to beat the fucking thing (dammit ADOM...).

Incidentally and on a mostly-different topic: you can always tell when I've gotten fuckall done in terms of actual writing of code when I launch into a discussion of very highlevel ideas and don't mention a class name even once. Well hold onto your asses, ass holders, because I also got code done since we last talked.

REEE-FACTOOOOOR.

Wow that sucked.

Moving the code to allow for extensibility of the dungeon to multiple floors WAS about as easy as I figured it would actually be if I just held my face to the stone of grinding and did the damn work. According to my log, it took about *checks log* 45 minutes. Not too shabby. There's still a bit or two that I'm not particularly pleased about where it wound up, but for now things still work and I'm cool with that.

I didn't actually add in the part where I let you go between levels, though that'll probably take half an hour by this point (because I added the Stairs class, now I just need to 1: put them in maps and 2: handle the transition-y business). Or no time at all because I'll probably do that before I post this, then change this to say "I did it." (If you're reading this then it means I forgot to edit it out. WHOOPS. nonedit: leavin' it in 'cause I'm tired and I think it's funny)

The fun part was when I decided to add XP to the player with every hit instead of with every kill (because it's bullshitty and annoying when you whittle a dragon down to 2HP and some dumbass mob comes along and shoots it with a -4 arrow of craptacularness but gets a critical, kills it, and levels up eight times, even though you CLEARLY deserve that XP).

I haven't actually done that yet. What I did was change the spot where I say the next state should be the levelUpState if you've got enough XP to level. I'd been returning how many levels you got from adding XP to the player, then using that result to say nextState(&levelUpState) in all two instances where I added XP to the player (one of which for debugging purposes). That struck me as being needlessly stupid, so I put that check into the addXP function itself. Which immediately gave me eleventy billion circular dependency problems.

Fun story: up until recently, I'd been just declaring classes/functions in .h files and implementing them right in those .h files.

Long story short, that was a bad fucking idea. (Obviously I'm not proud of it, but there was a reason behind the madness. It has to do with how you pretty much have to do that if you're using template classes, coupled with "I have yet to see the point of separating .h and .cpp, so I'm just going to leave them together until something comes up to show me otherwise." Basically, now I know otherwise.) I realized that to fix that I'd have to split all my .h files into .h and .cpp files. Which wasn't hard, wasn't tricky. Was just mechanical busywork.

And a fucking lot of it. When I started, I had around 20 .h files. And around 4500 lines of code. Because I had crammed several classes into a few of those files, I wound up splitting some .h files into two .h files, then splitting each of those into a .h and a .cpp (in one memorable instance, I turned a single .h into eight separate files). All told, it took over three hours of just cut-paste-tweakSyntax. Now I have around 60 files.

Basically: Cautionary Tale.