Unfortunately, some of the code (like my shooter this year, and many of my previous years' entries) uses custom tools to generate the source code (for embedding the encoded external data).  This makes a real annotation more difficult in those situations.

EA shut down some multi-player servers a while back: http://www.cinemablend.com/games/EA-Sports-MMA-Multiplayer-Shutting-Down-Soon-40599.html.  Not quite the same thing, though.  A better example, though not directly related, was when Microsoft turned off its music service: http://arstechnica.com/information-technology/2008/04/drm-sucks-redux-microsoft-to-nuke-msn-music-drm-keys/

As for Steam, this big long thread on their forums discusses what their plans are: http://forums.steampowered.com/forums/showthread.php?t=870603.  The tl;dr version is "Steam would revert to "Offline" mode."

I have several reasons why I would want to never have a game that requires this always-on connectivity.

Firstly, I commute by rail which claims to have wifi access, but it's slower than a 4kbps modem connection when it actually does work.  There are other times when I am using my laptop outside the house where my wifi does not reach.  In each of these scenarios, I may wish to spend a few moments on Popular Game (it's happened many times), and if it requires an internet connection, then I won't be able to play it.  This makes me much less likely to want to buy the game in the first place.

Secondly, any game that requires connection to a server makes me question my ability to play said game after that company has gone out of business, or if it decides that running its DRM servers isn't worth their while (like what EA did to its "older" sports titles).  While not a show-stopper for me, it does make me reconsider whether I should buy it or not.

It looks like some issue with the escaping - there should be a backslash ('\') before each u.  If you want to see the source control version, it's available here:

http://groboutils.cvs.sourceforge.net/viewvc/groboutils/projects/grobo-games/4kgames/rogue/src/R.java?revision=1.22&content-type=text%2Fplain

Nope, I missed that one.  Although, over these years I've only kept a limited amount of the code posted up here.  Most of it is either refinements of other code, or one-off snippets, but it would be interesting to see it all together in one place...  Hm...

I updated the my Java4k tools to include a trivial HTTPD server that knows how to handle pack200 file requests.

If you want to play along without downloading the whole package and getting it running, here's the simple guide:

1. Download the source from here: http://groboutils.hg.sourceforge.net/hgweb/groboutils/java4k/raw-file/28651c630d4f/tools/src/net/sf/groboutils/java4k/httpd/NanoHTTPD.java
2. (optional) Remove the package line to make the simple guide easier.
3. Compile NanoHTTPD.java
4. Put a simple html file named "index.html" and your pack200 compressed applet (named *.jar.pack.gz) in an empty directory.  For the html page, something simple like this works (replace the attributes in caps with the actual value; notice that the archive name ends in ".jar"):

5. Run the NanoHTTPD class like: "java -cp . NanoHTTPD -p 8080 -d (directory of html and pack.gz file)"
6. Point your web browser to "http://localhost:8080/"

I'll do some self-promoting here for this.  I have collected the different techniques at shrinking my game jars down into a Mercurial project, which can be downloaded here:



There's a readme file that will (hopefully) walk you through the setup steps.

Well done animation and special effects.

As for gameplay, I found that the normal bullets sprayed at the ship don't have to be avoided, because they do too little damage to the ship - the only real threats are the bullets from the bosses and colliding with the enemy.  The game would pose more of a challenge if the bullets did more damage.

The final version is up and live on the Java 4k site.

Thanks for the feedback.  I've uploaded yet another version, this time with more unit variations and (hopefully) better controls.  I had also felt the same thing about your ship's size, so the ship is now slim enough to slip between the wide enemy's bullets.

I've just uploaded the pretty-final version, and will probably be uploaded to the 4k site in a few days.

I've finished the conversion to string data.

Some gameplay changes I've added since the last updated version:
* no more lives.  You've got one life, so handle it with care.
* the purple gun heals your ship, and doesn't damage the enemies.
* bosses look better and have better shooting patterns.

Now all the game needs is mammoths falling from the sky!

I'm thinking about changing the mechanics a bit - the lasso (purple beam) will heal you and maybe have a chance of destroying bullets, while only the blue laser hurts the enemies.  Once I add in different bullet patterns, this may not be best, but I'm looking out for ways to make it different and interesting.

Very nice, and very hard - the three giants at once was tricky.  I loved the horsemen- I would have liked to see more of them.

I've reached my limit in file size for the large in-line static int[] version.  While I'm taking the long road of (finally) migrating this to a String unpacked version, I've updated the game to include boss fights.

All great comments.  This is just what I was looking for.

I'll work on the controls feel first.  My original concept was to make them very dependable, but needing a few tricks to get it to move exactly to where you want quickly (it makes sideways motion more dangerous - you can slide into some bullets that are off screen).  However, considering these comments and that, as a Java 4k game the average play time will be less than 5 minutes, I'll make the controls easier.


The code even notes this as a bug - the "stickiness" of your ship on the side of the screen.  Currently, the only way to see the motion is by noticing the background star field moving.  I want to change this to show ship movement.

The gun action might need some tweaking, but I'm going to leave that for once I have some preliminary ideas down for enemy motion and bosses.  The general concept is to make the player decide which weapon is better for a situation - the purple wavy beam which allows for maneuvering while still hitting the targets, but does less damage, or the direct ion gun blue straight beam which does lots of damage but puts you in more danger.

I currently don't have the code in place for scaling the objects on a per-instance basis (it's currently only in a per-template basis), but that should be easy to include, and will give some nice visual variations.

On!  The shooter where your gun is always on.

Java 4k Site

Final version was uploaded to the Java 4k site.

The game is now official on the java4k site.  Thanks Appel!

Great game.  I agree that changing the damage amount based on location would add more variety and strategy to the game.

Despite my best efforts, I couldn't get past Level 39.

I've been using Gentoo Linux as my main box for several years now without any major problems in regard to keeping it in working order.  I'm able to get the applets to work in browser (both with Chromium and Firefox).  As others posted, Eclipse works without issues.  Of course, having the POSIX tool chains available at the command-line helps my productivity, too.

I keep my Windows XP machine for games and ensuring that code I write is cross-platform compatible.  There's a few minor things that can be different between the two on a Java app.

Last year I worked on creating a bundle that can be used for an automated build.  I've put that into a new Mercurial package out at my bucket site:

hg clone http://groboutils.hg.sourceforge.net:8000/hgroot/groboutils/java4k

It doesn't bundle JShrink or yGuard due to licensing issues, nor does it include any of the compression programs.

Note that full builds with this can end up running for an hour, as it exhaustively checks different kzip settings to cut the size down by a few bytes.

Thanks everyone for the feedback.  I've incorporated all the notes you've given, as well as improved the game balance.

Bah.  I thought I had eliminated that, but I just saw it, too.  It's related to the generation of the map.  I'll look into this.  Thanks for the heads up.

You need to be careful with the MIDI approach.  If you look over the Java4k rules (http://java4k.com/index.php?action=view&page=rulesjudg:

... which leaves us with generated sounds.  Personally, I've had an issue with sound effects through the javax.sound.sampled is the delay between writing to the audio buffer and hearing it.  I've seen some systems have up to about a half-second delay, which means it's really, really tough to synchronize the audio with the video.

If you like those visuals, then you'll love this, if you haven't already seen it.

http://jtnimoy.net/workviewer.php?q=178

It's a description about the visual effects by the guy who did a lot of them, and how he went about making them.

Due to popular demand, Rogue4k is now in HD!

Hands down, my all time favorite game is the Little Big Adventure series ("Relentless" and "Twinsen's Odyssey" in the states) - yes, it's two games (and always the lingering hint of a third), but I count them as one.  Bonus points for those of you who see my attempt at a connection with it.

In terms of hours put into a game, I'll list these as best as I can recall:

• Ultima 7 (part 1 & 2)
• Team Fortress 2
• Warcraft 2
• Ultima III
• Ultima IV
• The classic Infocom text adventures (I'll just lump those together)
• Rastan
• SimCity 2000
• Thief
• Morrowind

I'd like to put Planescape: Torment on here, but I keep running into a crash part way into all the playthroughs I've done with it, in every imaginable configuration I can come up with on modern hardware.

I uploaded a new version.  This includes:

• fixes to the map generation (no more long strings of doors)
• text messages alternate colors, so you can more easily tell if a new message appears with the same text
• a few balance issues regarding monster strength and frequency of appearance

Most of the case statements take advantage of the fall-through feature to reduce code duplication, but there were some that I removed.  It seems to have helped to reduce the code size.  Thanks for the suggestion.

I don't have any experience with LWJGL, so I'm curious as to how much overhead it would add to an Applet versus using the straight Java2D libs.  I'm thinking about the constant pool size additional requirements for the class names and method signatures.  I know that's a subjective question, as LWJGL offers features not in the Java2D libs.

My question is really about whether users of LWJGL would have an "unfair advantage" over those who don't use it.  That itself is also a subjective question, because just by using a library doesn't make a game fun.

All in all, though, I'm in favor of expanding the number of games as long as it doesn't have an impact on those who don't use the library, or on the work load for the judges.