Thursday, February 25, 2010

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.

Sunday, February 21, 2010

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.

Thursday, February 11, 2010

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.

Tuesday, February 9, 2010

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.

Friday, February 5, 2010

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.

Wednesday, February 3, 2010

And Now for something Completely Different

So I've been working on a side-project in pygame for a while now. Probably long enough to constitute more than a side project per se, but whatever. Not gonna explain anything about it, but here's a few things I made it do that made me smile.
  • Implemented my very own Vector class. Not the vector that means "a smarter array", that'd be stupid (python, remember?). No, my Vector class is pretty much the backbone of the nifty-ish things I can make the game do, and best yet it integrates quite well with the tuples that pygame assumes I'm using anyway, so for system calls to drawing functions, for instance, I don't even need to convert my Vectors into tuples (because for all intents and purposes as called by a function, they behave pretty much identically).
  • Finally got bullet motion pretty much ironed out. Bullets spread out in a gaussian distribution, so shotguns are worthwhile at medium range. Collision detection is implemented in a way such that bullets "move" ten pixels at a time (currently enemies are 40x40 rectangles) so as to ensure hitting enemies even when moving at high velocity. Still to do: implement a recoil system where your rapid-fire guns are more accurate when fired in short bursts.
  • It's got explosions in it. Explosions are drawn to any arbitrary size based on the radius of said explosion. To draw an explosion, I draw circles on top of one another of varying color, starting with orange on the rim, passing through yellow in the middle, nearing white at the center. In order to keep from having to re-render each explosion each time it's called, I first check if the explosion is already stored in a list I've made. If so, I just draw the pre-rendered image. If not, I make the image, then draw it. This technique I learned while working on Rouge (which I will do more of eventually).
And for another aside: Mass Effect 2 is completely fantastic. I'll review it once I stop being too excited about it and can analyze it fairly.

Monday, January 25, 2010

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.

Friday, January 22, 2010

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.

Sunday, December 6, 2009

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).

Sunday, November 15, 2009

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.