Checking In

How did I spontaneously decide to choose today, exactly two months since I last said 'hi', to post again?
Seriously what gives; that was weird.

Anyway, as I'd been predicting I've been approximately way too goddamn busy with school-related assignments to do any real work on my game projects.

That said, I've miraculously found time to do a cool side-project or two. Worth mentioning: the thing I did that does recognizes numbers from user handwriting. Also, a 3d engine.

I'll post pictures of these theengs later on; cannae be arsed at the moment. So there.

Uh, yeah. Not dead. Woo.

What I've been up to

Nothing!

Okay, lies. That shmup I was making is almost nearly done. For serious. Except for the part where I need to actually make most of the content, and there's a few options I'd like to add, along with a few menus and the ability to save and etc. BUT, the big stuff is basically done.

Work on it in the future is basically horribly delayed, though, because this semester is going to be somewhat work-intensive most likely. I finally have games I need to make for class, so they should probably take priority over stuff I'd like to do instead. Also I stupidly forgot my tablet at home, and I don't want to make new graphics with just the mouse (and yes, I want more than four different types of enemy to palette-swap, and I want bosses to each be unique-ish), though I might wind up Shanghai-ing some of my artist-y friends (not too likely, sorry artist-y friends). Also it still needs a freaking title.

Rouge work will follow that, so it's something of a ways off. Which is a damn shame because my noggin is BURSTING with ideas, some of which provide interesting (horrible) problems/complexities I'd need to reconcile with each other. For example, having variable-sized enemies makes using better pathfinding algorithms trickier, though [an idea for] a solution exists.

Anyway, here have some proof that I haven't been sitting around with my thumb up my ass:

And here have one with the experimental (totally going in the final version) motion blur option:

Once again behold my not-wanting-to-crop-the-damn-image-ness.

Peace out, jerks; see you in two more months.

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.

Very Bad at Keeping it Simple

Haven't done anything to Rouge in a month. I've been coding, though; I decided to start a side-project to actually make a reasonably-finished game that's pretty simple and actually has realtime elements so it isn't so bloody fringe. The idea was to make something simple, that way I could conceivably actually finish it.

So, I started making a shmup.

I've had this idea bobbling around in my head about an upgradeable guns system in which you add points to various categories such as Power and Speed, altering the gun in a way you see fit. As you level up, you get more points to allocate to the gun, gradually improving it.

Then I figured that you should be able to have more than one gun and switch between them on the fly during a level, so you could have a fast, powerful gun, and a gun with lots of spread, and switch between them depending on whether you were fighting a boss or a bunch of regular enemies or whatever.

Then I got the idea that, in addition to just firing bullets in different ways at your enemies, you could upgrade your guns to use rockets or lasers or other stuff, which would have different base properties and the projectiles themselves would behave in other exciting fashions.

Then I got the idea that it would be really cool if you could use multiple guns at once, using the high-powered straight shooter as well as the high-spread gun, and a rocket launcher for that extra punch, all at once. To balance that, you'd get less experience for each gun (and each gun would have its own experience and level) when using more than one at a time, but you'd be able to disable guns on the fly (instead of switching between them). The number of guns you could have equipped at once would depend on the number of slots your ship had open, but you'd be able to keep an inventory of guns and move them to new types of ship that had different base stats and you could upgrade those in various ways, and you'd be able to buy different base weapons that behaved differently and upgraded differently and you'd unlock more and more combinations as you go through the levels and...

Aw, fuck.

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.

Philosophy III : Cutscenes and Storytelling

Fuck cutscenes.

Cutscenes are a pointless waste of everybody's time.

Okay, qualifying statements.

Cutscenes aren't completely useless per se, but only in small bits at a time. As in, over five minutes and you've hit time-waster status.

Now, you might need more than that to exposit things at the very beginning/end of the game, and maybe some longer things around the three-quarter mark where stuff starts to get climactic, so I'll go ahead and allow say four longer cutscenes in the whole thing.

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.

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.

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.