Actually

Screw it. Here you go: Duckbill-r20.zip (Google Docs)
Protip: Don't use either of the multiplayer options unless you have a penchant for ruination and failure. Or at least, crashes and failure.

Not much has changed for the single-player campaign, except that larger rooms use a different generation algorithm, and item placement has been improved a bit.
Probably 95% of the networking code is done, it's just that the last 5% will turn it from bugsy crashesalot, into actually functional.

Mid-week update coming hopefully soon, once I fix this damn thing. Then I'll talk for a while and it'll be lovely.

More De Lays

It'll be done when it's done, dammit.
Sweet zombie Jesus, this is a headache. Being so close to done and not having stuff work is mildly infuriating

De Lays

This week's update isn't quite ready yet, sorry.

It will be up sometime tomorrow - I know all three of you reading this are very disappointed.

Just know that, this was a huge headache:

Networking Base

Got the basics of the multiplayer in place. Tons of work left to do for it, but the big scary step into the realm of networking code has been taken. Details at 11 (i.e. Saturday).

Duckbill: Week 2

No time to talk, download this: Duckbill-r12.zip (Google Docs)

Don't worry that the revision number went down, that's because the revisions were reset when migrating from Google Code to Assembla.

Features:

- Random map generation

- Random platform generation

- Three kinds of item

- Lighting system

- Shoot badguys

Caveats:

- Maybe it'll hang when you create a new map. If it does, the chances should be slim, so quit and try again.

- You can fall into a room you can't jump out of. The entire map is visible from the get-go, so if this happens it's kind of your fault (see How to Read the Map), but it still sucks so I'm working on it.

- For that matter, sometimes the random platforms will generate in such a way that makes jumping to the next room difficult or impossible. I know how to fix it; that's coming up next week.

- Generating larger maps takes a while now that I'm placing platforms in each one.

How to Read the Map:

Color of room corresponds to how high it expects you can jump. The colors go Blue, Green, Yellow, Orange, Holyshityou'restillplaying. If a room is slightly darker with a gray outline, it's a darkened room, and you'll probably want to get a light upgrade before you go in. If a room has a red outline, there are enemies in it, and you might want to find a gun first.

Also: arrowkeys will move the map, and plus or minus will zoom or shrink it, respectively.

Screenshots:

Project Duckbill

Remember how I said it was open-source?
LIES.

I decided that I want to try my hand at maybe making some money off this someday. For that to work, I can't exactly have the source code available free of charge now can I? That and I'd only open-sourced it because Google Code makes you. Assembla? Doesn't.

Anyway, in the realm of good news, I got my scheduled features for this week done already. Which means I can talk about stuff for a bit.

Duckbill: Week 1

So I started fiddling about with XNA recently. As in, Tuesday or so. Here's the start of the engine that I got done this week. I decided I'll try my hand at Agile programming for a change, releasing early and often.

Here I've released far too early; there's more missing than there is implemented. In fact the game itself is little more than a platforming engine demo.

Enough stalling:

Download

Google Docs (.zip) 

Caveats:

Windows-only (for now and a while; it may be possible to release an XNA game for Linux, but I wouldn't hold my breath)

I have no idea what the system requirements are because I haven't tested the distributable on not-my-machine at all

I've decided that I will release a new version of this every week until unfeasible; i.e. school starts again or I get a job. This will serve to 1: give me deadlines, and 2: let people see a game evolve. The first is the most important, because the most crucial thing I've learned from taking Game Dev courses is just how much work one can accomplish with a deadline looming over you. Not only do they make you work for about twelve hours straight (probably not going to be killing myself like that for this, though), but they also make you prioritize what to finish and what to cut, or at least what to do after the important things are taken care of.

Also, actually releasing games helps make sure said games are usable. Rouge was fairly impenetrable to almost everyone but me, and most people didn't even notice the hastily tacked-on keybindings button I added at the last minute. This game has obvious instructions! And less keys! So far.

(Incidentally, I have too many plans for Rouge to really start anywhere on them at the moment. I fully intend to get back there again, but not at the moment. Maybe after I get busy again.)

What is this game, anyway? Codename Duckbill is a tile-based platformer. What it will become is a procedurally generated Metroid-style game with multiplayer support. I have barely any idea how to do that, but that's where the fun will be.

Oh, and it's open-source. Kind of. I won't listen to anybody who tries to send me code, but as per the requirements of Google Code, the code is open. It's here if anybody's interested. I'm using the MIT license, because as far as I can tell that's as close to the WTFPL as they would let me use.

Edit: realized I didn't actually distribute said license in the .zip file OH WELL PRETEND IT'S THERE

Alive

Turns out that when you're programming games for class, it leaves precious little time to program games for yourself because if you're working on a game that isn't the one you need to have finished by a certain deadline then what the hell are you doing?

Anyway, I'm exhausted beyond all reason. More on that later maybe.

Here's the game I spent the past semester on. Unlike the other games I've made as part of class, I feel comfortable posting this here because I made 100% of it. Well, other people helped get the initial design - in fact it wasn't my idea to start with. More on that later maybe.

Enough of my delirious rambling; game time!

Game name: Good Question

Genre: Cards

Difficulty Level: Confusing at First

Operating Systems: All of them, if you've got Python

Screenshots: if I feel like it (coming soon)

Downloads:

Google Docs (.7z)

Google Docs (.zip)

(more download links later/eventually, in case Docs decides to be a jerk or something)

The game needs Python installed, as well as Pygame and PyOpenGL

If feedback is alarmingly positive, I might keep going with this a little and include simple network play or better AI or something snazzy like that.

Coming soon: SLEEP

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.