Cutting work out for oneself

So, more and more recently I've been wanting to rewrite Rouge with OpenGL.

FUCK.

I just want to make it perfectly clear that I am under no illusions as to how much this is going to suck. A lot, and I mean a LOT, of things are going to need to be redone entirely. Mind you, a lot of things desperately needed redoing to begin with, so that's not even really a loss. And for the most part, the important game logic is still intact; I just need to change what's inside a few draw() functions and I'll be good to go (GROSS OVERSIMPLIFICATION AHOY).

The thing that hurts me is that a lot of (what I think are) my really cool design decisions get removed completely. Using SDLgfx to resize SDL_Surfaces gets removed in favor of just drawing a larger quad. My (terribly slow) colorMultiply function gets scrapped in favor of a glColor3f call. My hanging on to each image after it'd been processed is no longer necessary, as the processing time is now a nonissue. The hash table that ensured I only keep one processed image/color combination has no use whatsoever. The RGB function I'd made to limit the number of possible colors to keep the size of that table down is pointless and laughable.

Alas, I lay these pieces of code to rest. Let this post be their monument to existence.

Upon their headstone I lay the following benefits that this work-intensive move offers.

• Performance will be vastly improved; memory usage will shrink to at least a third of where it stands now
• I'll be able to more easily have several different-sized images next to each other
• Many pieces of seemingly-redundant code will be removed; drawing routines get easier
• The code seriously needs a good scrubbing anyway

This last point is probably the most important. I'm just going to go ahead and admit it, the code for each menu is horrible and ugly (and frankly, the menus themselves need work). Everything is done with strings, for god's sake. Example: to initialize the player's inventory, I pass a map < string, vector < pair < string, int > > > to the menu constructor, along with an ancillary vector in order to make everything the right color. This sort of thing is barbaric, insane, prone to errors (wasn't able to equip/unequip anything after changing the Item name-displaying code to use abbreviations), stupid, unwieldy, ugly, and a whole other slew of negative adjectives. Point is, it sucks and I hate it.

Where I'm going with all this: when I get back to working on Rouge, I'm not going to do anything to it for a while other than refactor existing code, improving architecture, and maybe doing some goddamn planning.

But first, I need to finish this shmup which I still don't have a title for. Deadline: end of July.

Rouge: Version 0.1.4

It's public release o'clock.

Necessary caveats:

• The Mage class is more or less useless, as there are no spells. For now, call it "hard mode"
• The dungeon caps at 300 floors, but I don't think anybody'll get that far. There's no 'goal' to the game as of yet
• Magic items are actually kind of boring
• Enemies are phenomenally stupid. They can't step on stairs (headache-related reasons). They can't pick up or equip items
• Lots of things need balancing. Some items are far more useful than others. Numerous formulae need to be scrapped and redone entirely 
• There's no way to save the game yet

That said, I won't bemoan stuff too hard. Here it is:

Windows: .zip .7z

Linux: .tar.gz

Somebody Save me

Saving. Hooboy.

This is gonna suck.

To save something, everything important must be written to a file. Every letter in a file takes up a byte of hard drive space.

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.

Oh, yeah

So, games.

Progress on Rouge has been, in a word, shitty. As in, I've gotten buggerall done. Part of me blames school, but more actually I blame other videogames for being too damn fun. FFXIII and Batman: Arkham Asylum, specifically. Mmm, Batman...

Anyway yeah. Where I'm at slash what I need to do is refactor the one of the bigger chunks of code I've got, which is, in a phrase, gonna suck. It's the same thing as when I needed to get the Item system done; a big chunk of stuff that needs doing all at once and without it I can get very little progress done. Or at least, very little interesting progress done.

I need to rework the main game state so I can extend the dungeons to have multiple floors. This sounds like it should be extremely simple, and it really kind of is, but I need to move a bunch of things to make it happen. And I'm really not looking forward to it. So I'm putting it off. Tho' it'll doubtlessly work out to be similar to what happened last time, and I'll get it done in about an hour later tonight. Here's hoping.

Version: 0.1.2

Oh hey look, it's been a week or so.

Shutting up and coding has been rather fruitful.

So, I'm done with version 0.1.2. At least. I'd feel almost comfortable saying it was up to 0.1.5, given that these versionings are pretty much completely arbitrary and I did a good lot of stuff. Rather, did one thing very thoroughly. That said, I'm going to stick with calling it 0.1.2, but might jump up a lot after hitting some key features for 0.2

Things to do for 0.2:

1. One infinitely-deep dungeon
2. Enemies and items that increase in power along with dungeon level
3. Backbone of the Skill system (the "No Useless Mages" clause)
4. Beginning stages of enemy AI (intelligent item equipping, decent pathfinding, skill usage)
5. Acceptably good battle mechanics (2-weapon fighting, holding one weapon in two hands, shield utility, basic combat balance)
6. A main menu
7. Being able to save/load

Philosophy II : On leveling

When it comes to RPGs, a character advancement system is something of a big deal. For some reason, I think there's very little quite as awesome as an interesting, rewarding system of character growth and advancement (then again, I think coding is fun, so feel free to take that with a massive grain of salt...).

So, naturally, it bugs me to no end when game developers screw everything up.

Okay, maybe I threw down that gauntlet a little too hard without qualification. Let me back up a bit.

Philosophy

I've been reviewing my changelog recently (not this devlog; the more mundane day-by-day "what I've been doing"), and I realize I've been spending a LOT of time tweaking the UI lately. Part of that makes me yell at myself a bit (stuff like "you should be doing cooler/more important things instead!"), but for the most part I'm completely fine with that. Thing is, the first, biggest, most major push I had saying "program a roguelike" was one simple thing: I wanted to resize the friggin' window.

Why yes, I have been working on this thing.

Gonna go ahead and say Rouge is up to version 0.1.1

Think I'll release the damn thing when I feel I can do so without having to qualify a bunch of stuff. This is independent of how nice an audience I can find for it; I'm still going to want to say "hey yeah you should ignore these parts they're not very good and this part'll be better later on and I'm planning on doing X in a later version and I really don't have the infrastructure for Y yet but I'm working on it and..." because I have grandiose plans for it and its current shadow of things to come is, frankly, kind of embarrassing.

Oh look, Pictures

Quick lookin' at some things I made happen (also, guess who didn't feel like cropping those screenshots?)

Picking a race to start the game.

The relative stats of each race are shown on the right (color-coded for convenience)

(more pictures after the break)

Version: 0.1.0

MAN that feels good.

Sixty-some hours of coding, 2,997 lines of code, and several friends repeatedly pestered, but it's finally happened.

I have something-resembling-a-game.

Details later, sleep now.

Rouge

The name is a joke.
The joke is, there's a good number of people who can't spell "rogue" properly. They surf the internets, looking for sweet new rougelikes to play. Little do they know, most people make roguelikes. My design is to answer the call for the rougelike genre, by creating it starting with the game Rouge.

Alternatively: This game feels badly for all the people who've misspelled Rogue over the years. This game exists to retroactively make you seem smarter.

Analyze THIS

So I finally finally found a lines-of-code (LOC) counter (by which I mean, I finally looked). And the results were a little surprising.

Turns out that, overall, Rouge has roughly 2500 lines of code. Woo. So far, the biggest thing I've ever written. And yet, compared with giants like ADOM, still barely even weighing in at fetal.

Speaking of Rouge, let's talk. So around, what, three months ago was it was the last time I mentioned anything about how it's going? Yeah, around there. Yeesh.

As far as my to-do list from then goes... we'll let's just go through each item

More monsters than just goblins (trivial, enemies already loaded from data file)

Yep, it was trivial. Making those enemies interesting, on the other hand, will be significantly less so. Making them level up properly is a relatively easy thing to do, but I'm putting it off for now because other stuff is more "hey guys" in-my-face.

Menus: class choosing (on levelup, when starting a character), race choosing

Yep. Talked about it a bit a few posts back. Not too terribly done I say now (but will bemoan it within two months). I've actually spent a pretty good amount of time making the menus shinier, so the plus/minus-es stats give you are now color-coded for your convenience. And because it's pretty? Doing so in a non-head-explodey way made me improve some basic-er systems, so it'll be easier to expand upon similarly-veined stuff in the future

Enemies attack you as well (trivial)

Here's actually where my biggest issue is, the thing that's technically the easiest to do. While I COULD add the four-or-so lines of code necessary to make this work (one/two for "attack main character" and threeish for handling potentially dying), I've been not doing so because it would make the proto-game I have now completely unfun. At present, there would be exactly zero chance of surviving more than three enemies, because of how my placeholder attacking algorithm works, because there's not too much of a strength difference between a 1st level monster and a 1st level player, because there's no way to restore lost health, and because there's no items to give a player competitive advantage.

Levelup capabilities

Easily done what with the whole menu-system THING; still have to program new-class unlocking, but right now my focus is more on the item system

Respawning, dynamically generated enemies

Dynamically-generated enemies is done, haven't made 'em respawn yet. Not too terribly difficult, but not going to do it now.

So, version-wise, where are we at? Currently, I'm skirting around making the item system. It's the next major thing I need to do to make this at all playable, because as it stands now the game is a nearly-realized engine. Which is pretty much saying it's almost to the point where it's almost-a-game. So it's around v0.0.9. When I put some basic items in, like a basic sword and piece of armor, then I'll turn on enemies attacking, and then I'll call it v0.1.

And maybe then I'll post some fucking screenshots or something.

The Menu for this evening

I've spent a good deal of time re-tweaking the menu systems.

One thing I've never been fond of in roguelikes is looking at a list of choices where half the things make me ask "what the hell is that?" And even if I know what something is, that doesn't mean I know enough to make good decisions about it. I can surmise that a Troll has higher Strength and lower Intelligence, making one a poor choice for a Mage character, but I can't intuit that trolls have slightly better-than-average Willpower scores, making them more resistant to magic, and I'm not certain whether this universe has the "trolls heal quickly" rule in play.

And while I could easily just tell players to RTFM (I mean, it is a roguelike...), there's no reason to assume everyone has prescient knowledge of the design decisions I've made to differentiate my world from the "standard fantasy setting" a.k.a. Tolkien (Our Elves are Better, after all).

So, I added a bit where you can see a description of what you're picking. Right now I've just got the stat plus/minus-es, but in the future that'll come alongside some flavor text for each thing. In order to actually see the description, I've added a cursor, letting you select which thing you want to look at. You can still just strike the key corresponding to the thing desired, for those who know what stuff is and just want to get on with it without having to scroll the bloody thing down. And you can jump the cursor directly to what you want to look at by holding Alt and pressing the corresponding key (which honestly feels a bit awkward. I'll probably change it to Ctrl, which involves changing a single character in the code thanks to my sexy, sexy Input class).

Programmatically, the coolest thing about the menu system is that it's almost completely modular. I used to have each MenuState class handle redundant things like making the list of stuff to show, handling inputs (from the Input class, of course), etc. Now all the generic stuff is put in the Menu class, and each MenuState has a Menu as part of it. Each MenuState now only has code relevant to the different things it does, which is the whole bloody point of classes in the first place.

Rumors of my Death would've been Greatly Exaggerated, but everyone knew I was alive

There's a metaphorical saddle that I'm presumably "back in" right now.
Here's a brief overview of programming-related Things pertinent to me at the moment:

• The amount of progress I had made on Rouge since my last post right up until yesterday has been precisely nothing. The past 24hours have been focused on transporting the files from a Visual Studio project in Vista to a Code::Blocks project in Fedora 12.
  
• It is remarkably easier to program things in Linux.
• Python is fantastically cool, and will probably be what I use to do a good chunk of other projects. I'm not rewriting Rouge in Python though, god no.

A Whole New World, Every Single Time

I'd thinking about how to implement a procedurally-generated overworld. Not yet looking at individual organic-looking tile placement, god no, but instead on how to organize a random world into an interesting underlying framework.

On the topic of things being interesting, my original plan was to make an overworld of wide open areas without changing the scale from dungeons or towns, with no way to travel on a world map (see Secret of Mana). Then I realized how terribly tedious and monotonous and repetitive and dull and uninteresting and dreadful and repetitive that would be, and thought instead of having a fast-travel option. I went back and forth between a Dwarf Fortress-style zoomed-out representation to travel quickly or a Diablo2-style waypoint option and select from a list of towns you've visited. It was the former which made me realize that, given the option, most (sane) players would choose the faster zoomed-out traversal, defeating the point of trying to catch their attention with repetitively repetitive repetition in the larger representation. It would also be tricker to randomly generate convincingly, and much more painful to try and save. So I decided to go with just the zoomed-out representation, because it's easier for me and less repetitive for you. Oh don't look at me like that. If this style of overworld is good enough for Final Fantasy, Chrono Trigger, and ADOM, it's more than good enough for me. More importantly, I doubt anyone would honestly want an alternative. Realism is only worth pursuing in videogames if it enhances the experience, and in this case it adds drudgery and repetition, not fun (a premise I'll cover further in an upcoming entry).

Okay I'm a Liar

Okay, so on reflection, I may have made a few misstatements last time.

Firstofall, the games is probably around v0.0.7 now; I forgot about making a menu system to initialize your character and level up and things. And implementing the menu system nudged me forth into finally rewriting the input system (more on that shortly).

Secondly, "Mechanics derived more from jRPGs" is probably a staight-out lie. Or at least a half-truth. Thing is, I am straight up tired of people just cribbing mechanics right from the d20 system and calling that their gameplay. So, a more accurate statement would have been: "Mechanics made up by me". I suppose this might constitute as throwing down a gauntlet, but for a genre consistently described as being the pinnacle of "gameplay over graphics", the mechanics tend toward similarity more often than not.

So, the new input system. Long story short, instead of each game state having to take into account keypresses, there's now an overarching input system that translates input into a string. Instead of having to say if(event.key.keysym.sym == SDLK_LEFT), I can now just say if(input == "left"). If shift is held down, it either capitalizes the letter where appropriate, or adds S to the front of it. If ctrl is down, C gets added to the front. If alt, M (for meta. Yes it makes perfect sense, just go with it). This simplifies things greatly when it comes to compund inputs. It also makes accessing items off a menus much, much easier programmatically. Instead of having to convert keypress inputs into an integer, then access the data at the right location, I can just iterate over the array and match the input letter with the item letter. It also makes editing the config files (which I will program sooner or later) much easier, as well as greatly simplifying the code for the "Help->Keybindings" command.

And now, in lieu of more content, screenshot time!

Human Warrior fights Goblins

Elven Mage faces off with a Goblin

Halfling Thief appreciates the randomly-generated level

The stats pane is deprecated. I'm probably going to put it on the bottom of the screen. And it isn't going to have every stat on it, but the more important derived stats (HP, MP, ATK, DEF), and XP  out of ToNextLevel (TNL). There will be a separate, more detailed stats page with a full report.

Finally, a list of things to implement before I consider the game v0.1

• More monsters than just goblins (trivial, enemies already loaded from data file)
• Menus: class choosing (on levelup, when starting a character), race choosing
• Enemies attack you as well (trivial)
• Levelup capabilities
• Respawning, dynamically generated enemies

For v0.2, I'm looking to have classes unlockable as you level, a multi-level dungeon, and the save system, among other things. Yes, this is getting ahead of myself.

Motivation

This is not the first game I've tried coding, and I dearly hope it is not the last. It is, however, most likely the furthest, most cohesive effort I've put together thus far. This is hardly surprising, because each of the proto-games I've made up to now have had similar backing.

And yet, invariably, my attention starts to wane eventually. I remember how much fun playing videogames is, or a fantastic new design idea jumps into my head and I feel as though that would be a more worthwhile project. Currently I'm avoiding purchasing Dragon Age: Origins due to the fear that it'll suck me right back out of this programming groove I'd only recently re-found (Borderlands managed to keep me from programming anything for over a week).

I ask myself what, ultimately, am I trying to do with this game?

I'm making a roguelike. As such, there's features it will have that can be described in terms of things other games have done already:

• Permanent character death
• Random dungeons
• Persistent dungeons
  
• Plenty of class-race options
• Lots of different enemies
• Magic/abilities
• Tons of items
  

That's well and good and all, but it's not exceptionally exciting per se, at least from a creation aspect. The reason being is that it's been done before, loads of times, in many/most other games in the genre. I can't speak for everyone on this, but I know that one of the main motivations for me to want to make a game is to take something I already like and make it better, or at least add some more features.

Here's an incomplete list of mostly-unique things about this particular roguelike:

• Multiclass characters
• Mechanics derived more from jRPGs (Final Fantasy, etc.) than tabletopRPGs
• Randomly-generated world
• Challenges that scale appropriately in difficulty
• Mostly random towns
• Acceptably realistic wilderness
• Varied, intricate item generation

Upcoming articles will have more to do with the second list than the first.

When both lists are reasonbly checked-off (i.e. implemented in the executable), I will consider the game v1.0. This is a very long way off. I'd estimate that the game is currently at around v0.0.7, and it's been around a month since I started (I forget the exact date). I'll call it v0.1 when I implement the message system and an attack command, because these are rather basic low-level systems that need to be implemented before I can rationalize giving the game any completion status.

I'll probably start releasing the game when I consider it v0.5 or so; where there's something that has a smidge of depth to it that's reasonably playable.

One fun Item

More and more I'm thinking about using a more Diablo-style magic item system than your typical roguelike, one in which the term "loot" might get passed around from time to time. This will all require me to implement items in general, but that's a task I'd have to go about doing anyway.

The plan then is to define various item types and base statistics which can then be modified by various adjectives. A semiinteresting consequence is that these adjectives can be magical or mundane, and these all will add up to some rather verbose item names, i.e. a Flaming Vorpal Sharp Iron Longsword of Balance and Pestilence.

On identification, the basic aspects of an item would be available at first glance; taking the above item as an example, on the ground the item would read "metal Longsword". After an Appraisal, something which should take a short but non-negligible amount of time (around a minute), the extent of the item's physical properties would be revealed, so the aforementioned sword would now show up as a "Sharp Iron Longsword". Depending on a character's sensetivity to magic, the item's magical nature can be known as early as seeing the item on the ground, or even from a distance if the item in question was of artifact-level power. At whatever point the item is revealed to be magical, the item's name changes color to whichever tier of power it belongs to. At that point, an Identify spell (available on scrolls, from the players' spellbook, or from some NPCs in town) would need to be cast to reveal the exact nature of the magic item, even though its effects have been benefiting the player from the time they equipped it.

A part of me thinks it could be interesting to have there be no easy identify - no Deckard Cain to tell you what things are for a negligible fee or less - and have the properties of the item revealed as the player's character observes their effects. But then, there would be little benefit to doing so, and the process of rubbing various combinations of weapons and enemies together would be more tedious than imaginitive, even though the process would in most cases be fairly quick (i.e., it's a simple matter of identifying Volcanic weaponry as it tends to set things on fire), and thus would be a good deal of work on my part for very little if any benefit on the player's part.

Have some Class, man

So I've been thinking more recently about game design rather than game implementation, which I suppose is a pretty good direction for things to take.

The next step is to make the combat system, and there's several ways I can start this.

1. Program the "attack" command; add "if enemy in tile you're stepping on, don't move, but attack", program the attack routine. Right now I'm thinking damage should look something like C*(A*ATK-B*DEF)^2 +- 30%, which is obviously not set in stone.
2. Program a "messages" subwindow to display "[Player] hit [Enemy]. [Enemy] missed [Player]" stuffs. Pretty straightforward, the trickiest bit is going to be knowing when to stop scaling the window that displays across the top of the screen. Actually it'd be pretty straightforward with a fixed-width font; when adding characters to a Message string, keep track of the length on the current line, when length > number_of_characters_that_can_fit_on_a_line ((screen_width - status pane width)/pixels_per_character), back up until a space is found, change the space to a newline, keep going until a fixed number of lines, prompt the player for more. The most annoying bit then is going to be handling the "more" input, but I'll just make it loop until the player presses something for now.
   
3. Add enemy "AI". At the moment I'm going to start off with a simple "always move towards the player" method which will generally keep enemies stuck in rooms, but occasionally allow them to come into a room from some adjoining hallway. It's also simpler than "if in sight of player move towards" both in terms of implementation and computational complexity (no need to scan what each enemy can see), so that's pretty cool. Also would need to add an "attack" check to enemies, but that's trivial enough to keep this nondependent on 1.
4. Leveling a character up.

#4 is the sexiest-looking, so I'm wanting to do it first. It also has a bunch to do with one of the real features of the game, the class system. And being able to make characters of multiple classes.

The player will start being able to choose from one of three to five basic classes like Fighter, Mage, Thief, and with each level up, the player chooses which class to put the level in. After meeting certain prerequisites, the player will be able to choose from new, more powerful classes with better stats and/or different skills, i.e. Knight, Ninja, Wizard, Necromancer, Ranger, and so forth. There's three ways I'd like to go about this:

1. New characters start choosing from base classes; unlock new classes as they level up, and may add levels in any class they have unlocked (allowing for Figher3/Thief2/Mage2 characters)
   
2. New characters start choosing from base classes; unlock new classes as they level up; may change into other classes a la Final Fantasy V, keeping levels. Class changes might be allowed in lieu of leveling up, but more likely will be allowed in safe locations. Or in the middle of a nest of spiders, but as it would take several hours it wouldn't be the most tactically-sound idea
3. New characters start choosing from classes unlocked in previous playthroughs, may add levels in anything ever unlocked

Because I'm weak, and can't make up my mind decisively about which'd be best, I'm thinking I'll have three different game modes. #1 will be Normal, #2 Alternate, #3 a sort of PowerMode just-for-fun type thing. Naturally, they'll all have their own high-score list, as converting the difficulty between them would be difficult and probably meaningless, or just straight up wrong.

In order to make things work across modes, I've thought of some (of what I feel are) interesting mechanics.

When you gain a level in one class, you get behind-the-scenes points in several categories. For example, instead of needing to be Fighter5 in order to access the Knight class, you need 5 points in the Warrior sphere, and every time you level Fighter you gain 1 point in it. This allows multi-class upper classes (like a Spellsword, Hunter, or Bard) in Mode2 (where you have no more than one class at a time), and greatly streamlines the unlocking of new classes (why can't a 200th level Fighter be a Paladin when a Fighter5/Knight10 can?).

Gaining new spells is something I'd like to have happen at each level. To this end, something similar to the class progression will be used. When you gain a level in a class, you gain percentage points in one or more skill disciplines, and when those points exceed a certain threshold, you can choose a new skill or two. For example, a Wizard would gain 115 Black Magic and 45 White Magic, where a Priest would recieve 150 White Magic. As you add skills in each discipline, the threshold increases and the number of skills available would increase (so newbie Mages can't pick ApocalypseIV as their level 1 spell, but could after mastering 24 other spells). I like the notion of picking your spells at regular intervals because it relies less on random chance than finding spellbooks. Never finding attack spells for a character would doubtlessly be intensely frustrating to most aspiring Wizards.