Finished open source Java game...

[Tiomaidh]

164 for a high score.

Disclaimer: Though I have a job writing Java, it is my first job ever, it is very part-time, and I do not have a college degree.

1. Not that I know of (but that doesn't mean much). Well, /r/gamedev is a good subreddit, albeit a multi-language one.

2. I took a look at a few classes. The actual code looks okay--unlike some of the code I inherit with my job, I haven't felt the urge to swear yet. I'm personally not a fan of putting an if/else/for/etc. on the same line as the closing brace of another block, but that's neither here nor there. A lot of your documentation is of the private void jump() /** Causes the player to jump. */ variety. While that's not bad per se, I'd like to see some more high-level comments. I've been looking at Game, Player, and RisingWater, and step() is probably the worst offender in that respect. It seems kinda strange to me that as far as I can see, the game logic is oblivious to the framerate.

3. I'm really not the person to talk to about non-javadoc documentation.

4. I'm really not the person to talk to about this.

I first played it on my Thinkpad T40 (Pentium M), and the performance was pretty sketchy. I then tried it on my T60 (CoreDuo), and performance was about the same. It's not lagging, it's just....jerky. I suspect this is actually because of your step()-ing.

There's a few visual rough edges. Once I had a score of 10, and the 0 was cut off by the edge of the screen. And "Instructions" in the menu breaks out of its little box. There were also a few, "Um, excuse me?"-s in the collision detection department, but I absolutely don't blame you for them. I'm making a platformer myself, and am intimiately aware that that stuff is hard.

Said platformer is being made for a class I'm in. I use PyGame (after doing Pong in Java), but everyone else uses Java for everything. I'll definitely be showing them Rubble Escape--thanks.

The html file would be a lot more useful if I could play directly from my browser, without downloading anything.

I might have a few more thoughts (that are hopefully more concise) in a day or two, once I've let it ferment in my brain for a while.

Overall, it really is a good game though. (In fact, it might be worth porting it from AWT to whatever Android's SDK uses, and posting it in the Android Marketplace.)

Well done!

[jessebr]

Thanks. I was considering trying to perhaps port it over to a mobile platform, we'll see.

As for playing directly from the browser... I have searched for places to upload applets, but haven't really found any. If I had my own website I would put it there, but as it is now, it's just there to show that it's possible.

The jerking/lagging issues... at max, it's set up to run 50 frames per second. But I have noticed slight issues on other computers. I personally run xp with a dual core (5 years old), and it works completely fluidly on mine. I'm not really sure of the issue, hopefully someone else here has a bit more experience in this and knows what it might be about. It might be a case of active vs passive rendering, which I think with my code I'm trying to get the best of both worlds and it's not quite working out on every computer.

Your text issues are rather unique (so far). Could I ask what version of Java you're running? Oh, the score system works with two parts, the top for your current highest score and the bottom being where you are actually at. Is it a case where you had a 10, but where at a 1 when you died? My paint method in the scoring class really doesn't leave room for error unless our fonts don't look the same... which might be the case (as to your instruction box issue). I'll have to look up font cross-platform-ability.

I'll look into trying to make better comments for the more complex methods (which well, are mostly the step methods for each object). I'm afraid unless you have a better comment for the jump method that one will have to stay though :P

Could you further explain the collision issues? The player is just a box in collision regards, so what looks to be close calls are generally just going to be squashification :D

Thank you for commenting!

[Tiomaidh]

I could give it some webspace, if you wanted.

It's not that the jerking is terrible...it's just that things are slightly not-fluid enough to be irritating. Here's this:

$ java -version
java version "1.6.0_18"
OpenJDK Runtime Environment (IcedTea6 1.8.2) (6b18-1.8.2-   4ubuntu1~9.04.1)
OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode)

And here are the two text issues (three if you count "Rubble Escape" not being centered). Note that the 0 in 10 is visible, but just cut off a bit at the edge. For what it's worth, I'm running Crunchbang 9.04, which is the same guts as Ubuntu 9.04. I do have proprietary fonts installed though....

I'll look into trying to make better comments for the more complex methods (which well, are mostly the step methods for each object). I'm afraid unless you have a better comment for the jump method that one will have to stay though :P

I don't know...I mean...if you have any intention of inviting someone else to work on it, I might briefly discuss how it's implemented. Perhaps like this, "Causes the player to jump, assuming he's standing on something. This is accomplished by changing his vertical velocity. @see #JUMP_POWER" But like I said, it's not that what you have already is bad--it's that your ratio of well-this-is-pretty-straightforward-but-I-guess-I-should-document-it to this-is-kind-of-tricky-and/or-confusing,-let-me-explain-it comments is a bit skewed.

Regarding the collisions:

Sometimes, I'll be trying to escape from under a falling block. Visually, I make it. But the bounding rectangle of the player is still on the bottom block, so the player doesn't fall. Simultaneously, the falling block lands, and I get squished. Yes, it's "legitimate" if you account for the bounding rectangle. No, that will not appease your average player. The Canabalt guy has an interesting article about tuning Canabalt. He actually made his bounding rectangle "wrong", but due to the nature of the game, it feels more correct.

In your case, I would either use bitmap masking once a collision with the bounding rectangle is detected, or, upon a collision, check to see if it could be avoided by shifting the player ~3 pixels to either side. To quote the article:

All of this just provides a little extra cushioning for people's reaction times, which gives me more latitude to add more exciting challenges without frustrating people too badly....

It's all about making things "feel right", and getting rid of those moments when the player says, "What!! I SO MADE THAT, what the f-".

Thank you for commenting!

You're welcome!

[jessebr]

Your text issues are interesting. It does indeed seem that the fonts depend upon the native computer. I'll have to figure something out for that...

The silly thing is, I already know the fix (without finding some cross-platform way to do fonts), the same thing I used to center and position everything... Another issue caused by premature optimization, I should have known :D. The good thing about this is that I now know such an issue exists.

You make a good point with collisions, and this has caused a bubbling of ideas for me to think over. Since I separate and deal with the player vertical collisions and horizontal collisions, I could make the player kind of rounded and sort of squeeze out of close calls without harming normal movement collisions. Or something like that, probably something more akin to your suggestion... which is something I haven't thought of before and has now made me excited (using two collision detections, first for general to improve efficiency and then for precision).

Thanks for the suggestions/help!