Thanks for the interest, but I'm actually not looking to collaborate on coding... I might request art and audio help later, but I personally prefer solo projects. (I work on big commercial games for my day job, so indie development is more of a personal hobby for me.)

Neat idea, random cards would nudge players into trying different abilities instead of always sticking with just one or two moves they're comfortable with. There could be characters with their own particular decks and coin acquisition rates--lots of vectors to balance upon.

Those of you REALLY without people to test your game with, consider coding AI and bots to complement your game! Machines need fun too!

Hurp durp! I read this whole thread looking to see if anyone had already asked about bots but totally missed Melly's updated rules.

An idea I like to make the pace of a turn-based game more frenetic is to make the turns not only timed, but ending whenever the player does an action. The faster he ends, the higher the effect of the action (within reason). This encourages fast, furious play, but it's a risk-reward juggle where going too fast may make you do soemthing stupid your opponent can exploit.

Ooh, I like that! I was thinking about a kind of speed chess thing where each player has a large pool of time available for all their moves (in addition to a short per-turn timer). But tying the speed of a single turn to the strength of that turn's action is more immediate, and there's no degenerate case where a player loses by completely running out of time.

Melly (and Derek, if you're around), what are your thoughts on allowing bots for solo play?

A very liberal interpretation of the rules could be that each game must at least support true player vs. player but may also include bots to sub in for one or more players.

It doesn't quite assuage the primary concern about the Versus compo (that lots of people sadly won't get to experience these games as they are intended), but it could help. In most cases, these kind of games would not be very fun with bots, but people could at least get a feel for what the game is like and maybe decide that it looks like a lot of fun and they really want to find other people to play against.

And I don't feel that it violates the spirit of the competition because each game absolutely must support two humans competing as the default mode.

TKtics is a turn-based strategy game for two players. You'll need a friend, as there's no online play.

More details in the readme.

Download:
TKtics (Windows, 511KB)

http://itunes.apple.com/us/app/codetogo/id382677229?mt=8  

I think it compiles/runs your code on a remote server or something, so I'd watch the legal/licensing implications of that if you're compiling proprietary code or somesuch, but it sounds like what you're looking for?

Sweeeeeeeeet. I'm so buying this when I get home.

Real-Time Collision Detection. If you're interested in the subject, obviously. It's the best and most useful game programming book I own (and I own a lot).

AI Wisdom series has some good stuff (though your library doesn't have the volume I'm published in... )

They don't have Lengyel's math book or Essential Mathematics..., but they do have Fletcher Dunn's 3D Math Primer. I think that one was pretty good.

Is it maybe running at exactly 60fps in both cases because you're vsynced?

Counterpoint: It's always valuable to write something yourself. You learn more that way. I know a lot of people here would probably disagree with me, and I think it's important to draw the line somewhere (you know, before you end up developing games in your own custom language, in your custom IDE, running on a custom OS, on custom hardware...). But I draw that line much lower than others--I've never even considered using Boost, and I've even abandoned STL in my current projects.

  EDGE

I've written an HTTP-based leaderboard for a non-browser game. I was surprised by how simple it was to get it working (using Winsock in the client and Python on the backend). Also taught me a bit about encryption and security. Maybe someday I'll ever release that game and find out if it all really works.

I also like the idea of having a web server that could push patches or new content to players--keeping them up to date on new versions of the game without having to seek it out at a website. Haven't tried implementing that, though.

Immediately to the left of my monitor is a bottle of contact lens solution, a water bottle, and half a dozen action figures.

But to my left is a Nerf Stampede (fully automatic foam dart gun). I will take that.

A lot of people seem to have major misconceptions about open source, even in more coding-oriented communities such as this one. Some people here even paint open source in a bad light due to those misconceptions, which is quite a shame. Perhaps I should write a tutorial about open source geared towards indie game developers...

I think there are some legitimate concerns about GPL--mostly, I would never use a GPL-ed library because I want the choice to not open source my own projects. So for me, it's a zlib-esque permissive license or nothing.

But a tutorial on the meaningful differences between open source licenses would be super useful. The information is all out there already, but I don't think I've seen it consolidated and presented with respect to game development especially well.

Grats! I need to revisit 8:Capsule, apparently. I couldn't make sense of the first level. 

Perhaps you could use the macros __DATE__, __TIME__, or __TIMESTAMP__ as part of your salt, so that you can release the source without revealing what unique salt you're actually using on your server and released client. Or just define your salt in a header that you don't release publicly, I guess.

The problem is that the client AND the server have to have the same salt without communication. __DATE__ would work, I guess, though when you can crack the code for one day, I don't think it would be too much work to crack it again for another. Just one more layer of obfuscation.

Yes, of course. I'm assuming you'd know what __TIMESTAMP__ was at compile time and what the resulting salt was, and you'd configure the server to match. I'm not assuming that every person who builds the game will be able to run on any server that anyone else built. Obviously, my suggestion would fail under those circumstances (by design).

Perhaps you could use the macros __DATE__, __TIME__, or __TIMESTAMP__ as part of your salt, so that you can release the source without revealing what unique salt you're actually using on your server and released client. Or just define your salt in a header that you don't release publicly, I guess.

Woo! Great work on the trailer!

This is so getting tweeted right now.

SVN suffices for my personal projects. Not really sure why you'd need distributed version control unless you're working with a team.

I love the graphics for this one, and the sound is pretty good too, but the controls are horrendous for me. In the end I gave up trying to collect any guitars, picks, or tapes as attempting the jumps would always kill me. Then I gave up altogether on the second level as I found it far to frustrating. Judging by other people's comments though it looks like I might just be rubbish at the game.

I doubt you're just rubbish at the game; the jumping physics and controls have definitely been divisive. For what it's worth, I think it's probably easier to play with a gamepad; but it's also a game which I wanted to make as difficult as possible without being unfair. My metric was that it should be possible for a skilled player to run the game in one life, so anything so difficult or random that it could not be overcome with practice was cut. (The one exception is the final boss, because hey, it's the final boss. It should be difficult for even the most skilled player.)

I tend to prefer Super Mario Bros. style platformer controls (Guitarguy is secretly an homage to Mario--the "flagpole" jump in the third level being the most explicit indicator as such). It seems that many indie platformers prefer inertia-free motion, which allows for more precise jumps but makes the character feel massless. Likewise, the weightier feel of Guitarguy isn't everyone's cup of tea.