The game’s entry is here.

Anyway, here’s a sneak peak of the title screen graphics. The game’s tentatively called “Islands: Through the Sweep of Stars”, which is a perhaps a bit more pretentious than I’d like. Any suggestions?

See you all again tomorrow!

I’m not yet sure whether I will participate – it depends on the theme as well as on how much time I will have to spend on other commitments during the weekend. If I do participate, I’ll be using either Slick or plain Java. In any case, I wish all of you a nice contest – I’m sure it’ll be loads of fun.

Screenshot:

I haven’t really settled on what tools to use yet, but I’m going with some form of Java – either LWJGL, Slick or just the standard API. On top of that, the usual set: Gimp, SFXR, MSPaint (yay!). If I feel inclined to do something in 3d, I’ll also use Wings3D. I sort of feel like doing something with shaders, but I expect a lot of people won’t be able to run it if I do :/

It is quite possible that I will attempt to make a game to fit both into the Ludumdare 48h and Java4k contests, and submit it to both.

Cavernous Shooter! is a top-down shooter set in a cave environment. Try to fight your way through the entire cave system, using the links below:

Windows / OSX / Linux / Source

Java Webstart

Controls:
[WASD] or [Arrows] to move
[Left mouse] to shoot
[Right mouse] to fire shotgun (if you have ammo for it)
[R] to reload
[Q] to toggle particle quality settings

The linked zip file contains .bat and .exe files for Windows, or .sh for Linux and OSX. It also contains the game source code.

There is also a web (Java Webstart) link – just run the .jnlp through your java/bin/javaws.exe (most browsers will default to this behaviour).

Anyway, I’ve made some progress, as shown below. There’s also a little webstart demo if anybody wants to try. It’s not quite what I’d like my game to be, but it’s better than nothing.

Play the demo

Some of you may also have seen this via the gamecompo mailing list, if you’re signed up for that. I hope to enter the competition myself, though I’m a bit pressed for time.

Game evolution

On a scale from “Amorphous Blob” to “Rigid Idea”, this is where my idea fits in:

In other words, I had pretty much settled on what idea to use. I was also pretty certain I would be using Java as the language, Slick (an OpenGL-based 2D library) for graphics rendering and SFXR for sound. Despite being relatively sure about what I was going to do, I didn’t get as far in the first day as I have in past contests. I more or less had my technology working, but no game to speak of. The second day, I woke up with a terrible headache that prevented me from working on the game for a couple of hours. Something was clearly wrong (see the image to the right).

A bit of technology

Before discussing a few gameplay issues, I’ll try to explain how the underlying technology used for the arrows and stars works. The stars are in fact controlled by a vector field with relatively sparse density (every 20 or 30 pixels or so). Each vector will turn downwards and change its length according to the strength of gravity over time. When an arrow is drawn, a new vector (that points along the arrow) is added to the vector field at every point in the arrow. This means that multiple arrows will create a stronger effect. For each star, the closest four vectors are then interpolated and added to its velocity once per frame.

The vector field without gravity looks something like in the screenshot below. Note that the arrows faded out a bit too quickly compared to the vectors when I took this screenshot.

What went wrong

Shooting mechanics: I spent a fair bit of time tweaking the rain, gravity and arrow effect mechanics, trying to make it fun. Despite this, a lot of people have said that the arrows did not work as expected. The general sentiment seems to be “I expected the stars to follow the arrows closely”. I can appreciate this, and I did have this plan in mind briefly. In retrospect, I should probably have abandoned my attempt at making a somewhat more “correct” physics model, and instead let stars follow the arrows.

Rain: Having the stars fall down from above seemed like a great idea, but in reality it just made sure that the bottom of the screen never got any “ammunition” to use. A few alternative approches that I could have used are:

• Letting the stars be “attached” to the sky, leaving a limited amount of ammunition per screen. With this approach, one would need to be more careful with arrow drawing (to avoid wasting ammunition). Perhaps stars could also grow back over time.
• Having stars come from particle sources to the left or right, thus avoiding the “no stars in a given area” problem.
• Creating stars for each arrow – perhaps they’d stick for a while and fire a couple of stars before disappearing? This could be coupled with more limited arrow-drawing and enemies that can only be shot from below, or behind, or at a certain point.

Lack of variation: The game lacks variation. There needs to be more enemy types and more variation in the shapes you’ll use for the arrows.

What went right

Visuals: I am primarily a coder, and not an artist. Despite this, several people have said that they liked the visuals of the game, and that is something I am happy with. While the arrows don’t quite match the pixelated style of the rest of the game, I think that the overall style is rather coherent.

Proof of concept: Having more or less settled on the idea in advance, I knew turning it into a fun game would be a challenge. However, I think I got at least halfway there, and I feel confident that further experimentation with the concept could yield a fun game. Several people have also told me that the mechanics may be suitable for touch screen or Wiimote-style controls.

Polish: Even if I didn’t have time to fully develop the gameplay, I think the game feels relatively polished; I’m happy with both the title screen and game over effect. I often skip both of these when making games, but taking the time to make them was well worth it.

Conclusions

Visually and polish-wise, I am happy with the results. I’m also relatively satisfied with how the game turned out overall, but I feel the gameplay could have used another day or two. A little bit of variation and better shooting mechanics could’ve made this game a lot better!

This was my third time participating in Ludum Dare. Once again, it’s been a lot of fun! I’m looking forward to competing again soon.

Here’s a screenshot of the title screen from the final version:

…Okay, I exaggerated a bit in the post title. There’s just one stick figure. Sorry :/

I have fixed this and uploaded a new version to my site as both zip and webstart:

• Webstart
• ZIP file

Sorry about that!

Sadly there was a tiny bug in the final version of my game – the line “state = STATE_LEVEL;” was missing, so no pause screen would be shown between levels (although the code for layout and mechanics of that screen was already in there, as can be seen in the source).

I have fixed this and uploaded a new version to my site as both zip and webstart. I realize that this may not be taken into consideration when judging the entry, but I thought I should at least upload the entry as it was meant to be (and as I was certain it was!)

• Webstart
• ZIP file

Sorry about that!

—

ORIGINAL POST:

Okay, here’s the final version of “Sky Upon Us!”, my entry for LD14.

I tried to upload the zip file containing launch files for Windows, Linux and OSX to the blog. Sadly, WordPress wouldn’t accept it even if I changed the file extention. Meanwhile, the game can be downloaded or started from all the following links:

• SkyUponUs.zip (Including Windows .exe and Linux/OSX .sh files)
• Java Webstart 1 (Java 1.4+, retroweave)
• Java Webstart 2 (Java 1.5+)

While the game didn’t quite turn out the way I hoped, I’m still happy with most of it. However, the gameplay does get a bit repetetive; excuse!

As always, any comments are warmly appreciated!

A screenshot from the game:

I’ll be using either Slick, which is a hardware-accelerated 2d Java library, or ActionScript3 for this contest, I think. Or fall back on Java2D if I don’t want to use the others for some obscure reason.

I’ll be using some of my SlickTemplate if I use Slick, or my Template4k if I go with Java2D, I think. Both are very short, smallish templates that really don’t do anything besides setting up a frame and saving input states.

That’s all for now. Good luck in the competition, everyone!

I forgot to provide the source code until just before the deadline, and my Internet connection wouldn’t work the last two hours before deadline. Anyway, here is the source:

Sourcecode (not very pretty, mind you. It’s rushed 4kb code.)

—

I’m done!

My game is called Tekicars4k. My plan is to enter it both into LD13 and the Java4k contest. In other words, it is a 33 hour 4kb game with the theme “roads”. Thanks to the size limitation, there is a grand total of 6 levels available. It is available as webstart and as a CompoGameLoader ZIP file, which has .bat, .exe and .sh (so should work on any OS).

Webstart (note: this version may be updated after the contest)
Zip file

Some instructions:
The goal is to place blocks in advance so that each Tekicar reaches an exit of the same color, without colliding with any other Tekicar. Walls will turn Tekicars clockwise, roads will speed them up, and arrows will re-direct them along the arrow.

As soon as you click “Go!”, the test begins – if you pass, you reach the next level.

Note that the ZIP file is way larger than 4kb, mostly thanks to the .exe wrapper. The game JAR itself is only 4kb.

A screenshot:

Demo

I’m afraid I won’t be able to add a lot of maps though… I’m aiming to do this in under 4kb (so I can submit the game to the Java4k competition as well), and I’m almost out of space.

Screenie, in case you can’t try the demo:

I don’t really have the time to make games right now, but I’m in. I spent one full day studying though, so might run out of time too soon.

I’m going to attempt a themed 4kb java game within ~33 hours… many of which I’ll be sleeping. This should be interesting!

So far, I’ve got almost nothing: