Gravitator4K

Contests 4K Game Competition - 2006
#1

Here’s an early version of Gravitator4K.

The game is fairly simple, and is controlled via mouse. There’s a particle fountain randomly placed on the left side of the screen, with a blinking blue target randomly placed on the right side. You click on the screen to create gravitational masses (left click for attractors, right-click for repulsors). You can place up to 25 masses on the screen, but not inside the target area. You need to get 100 particles to the target in 60 seconds. Each level up, the target decreases in size a little.

The level difficulty really doesn’t change much, and I still need to work on this.

SCREENSHOT:

http://www.curiouskangaroo.com/4k/gravitator4k/Gravitator4K.gif

NOTES:

  1. I’ve only tested this with Java 1.4, not 1.5.
  2. I have not tested this on Mac or Linux, only on Windows so far.
  3. The machine being used for testing is a 2GHz P4 running Windows XP, with 512MB of RAM.

JAR File (2836 bytes): http://www.curiouskangaroo.com/4k/gravitator4k/g.jar
JNLP File (707 bytes): http://www.curiouskangaroo.com/4k/gravitator4k/Gravitator4K.jnlp

I still have some work to do, but I welcome any comments. For this game, I have not yet used any special compression techniques, so I do still have some room to play with.

#2

Cool game, but if I run it through JWS using Java 1.5 Update 2 on Windows XP (latest SP and patches) I can’t see the bottom of the window as intended: Example

Apart from that little flaw it’s nice. I just poked around with exactly that sort of physics for a 2D planet simulation. :slight_smile:

#3

Nice idea, but in level 4 the destination-thingy gets way too small :slight_smile:

You could make it more difficult by having more than 1 emitter

Or having more that 1 destination, with a certain amount of particles required per destination

Or both! :slight_smile:

#4

Thanks, I’ll adjust the placement in my next update.

#5

Thanks!

Yes, figuring out exactly what to do with the levels is going to be my challenge for the next few days. I’ll play around with the idea of multiple destinations/emitters. What about color-coded ones? For example, white particles need to hit a white target and blue particles need to hit a blue target.

Also, if possible, I might play around with making the masses draggable.

#6

Making masses draggable makes it too easy, way too easy. You’d only need 1 mass then, and drag is around a bit until it’s in place.

#7

cool game

you could save yourself some bytes if you stop listening for keys (just have the game start with the click of a mouse since the keys do nothing else anyway)

#8

The idea with color codes sounds nice. I think the goal circle for the particles should never be smaller than an emitter, but it’s just me (it’s hard to tell where it is sometimes).

#9

Ok, modified the game to include multiple emitters/goals on higher levels. Made the particles themselves a little bigger. Goals don’t start shrinking until level 6. Replaced key-press with mouse-click. No draggable masses. Number of masses you are allowed increases with the number of goals. Number of required “hits” in the center of each goal. Text doesn’t go as far down now.

Used proguard/jarg/kzip (originally the class was small enough just to use normal zip compression and no classfile optimizers) so the jar size is now smaller than before.

Link above still works, I just replaced the jar file. Also replaced the screenshot.

Still plenty of room for more code, but I’m not sure how much more time I’m going to have.

Any other suggestions or comments welcome!

Strategy hint: setting up multiple successful streams at once is cool, but sometimes it is easier to concentrate on one at a time… as long as it doesn’t take you too long to set it up.

Hint #2: when placing masses (or anti-masses) far away from the emitter/fountain, gravitational effects will add up significantly by the time the particles travel far enough. Also, since all particles are affected when you place a new mass, even far away ones, expect your particle stream to change sometimes ten or fifteen seconds AFTER placing the mass (enough time for further away particles that were perhaps just emitted when you were placing the mass to travel across the field).

Hint #3: anti-masses are good for completely reversing particle flow when the emitter is facing entirely the wrong way… otherwise they can be used to “nudge” a stream, but should probably be placed further away from the stream than you think.

EDIT: I’m able to get up to level 4, score 159777. Haven’t passed level 4 yet, though.

#10

I thought id give your game a go and got to level eight before i stopped to get ready to go out.

see the screenie blow:

http://www.java-gaming.org/forums/index.php?action=dlattach;topic=12578.0;id=313

#11

Got to level 7, before quitting 'cos my sore throat is realy hurting :-\

360000

The new version is much better - is it my imagination, or do each of the particles also attract one-another?

#12

Thanks! Inter-particle attraction is just your imagination. However, it is important to note that when you place a new mass somewhere down the “chain”, it affects everything on the field, even particles very far away. What happens next is that you see your mass immediately affect nearby particles in some fairly obvious way… usually the way you intended. However, over time, as the distant particles finally arrive near the mass, they will behave slightly differently than the nearby particles did and will take on new trajectories. This behavior is pretty non-intuitive and can occassionally look like the particles are affecting one another. Also, there is a granularity to the simulation - this means that even if you settle down to a steady-state situation and never add new masses you’ll still see occassional variations in particle trajectories from one another, even though they are starting at the same point at the same velocity being affected by the same masses.

#13

This came is amazingly addictive! I’ve been totally hooked for the last few days and keep going back for more. The only problem I have is that I can’t see the numbers when the targets get small on the higher levels! Also I’ve found it’d be nice to be able to pause it (work calls). Just goes to show a bit of originality can produce a really playable game. And in only 4K!

#14

I do intend to do additional work on it after the contest. Thanks for pointing out the problem with higher levels… I actually haven’t had the time to get that far myself! Also, I’ll release the source code. Maybe I should set it up as a project on java.net? If so, it may need to get reworked into something a little more easily maintainable. When you’re shooting for small size, good design goes out the window! If this were developed into a full-blown game, for example, I’d want to add sound, and I’d want to upgrade from the 1.0 Event Model, among other things!

I also imagine an “Evil” level where the playfield is a solar system, with planets orbiting the sun. Try to shoot your targets with any accuracy THEN!

Thanks for the compliments, by the way. It means a lot to hear when people enjoy playing your game! It’s more important than winning or losing the contest itself.

And this game currently weighs in at only 2.77K

#15

I should get a super bonus for not using a single mass to complete this level. ;D

#16

It is suprisingly addictive. I have made it to level 14 so far, but could not continue playing. Like suggested, a pause key would be really nice. Especially when nature calls. Also it seems on later levels that some emmiters shoot particles at a lower rate than others. A lot of times I am wating 2-3 seconds between particles to finish the last target while others are just spitting them out left right and centre.

#17

Thanks! Pause is definitely high on the list. As far as the particles go, there is one piece of code that controls all emitters. The emission rate is constant among ALL emitters taken as a whole. So when you’re not seeing one emitter shooting particles, that means another one is actually doing the shooting. Even with only two emitters, if you look closely you’ll see that they’re never shooting particles at exactly the same time. Basically on higher levels I was worried about the sheer number of particles. The program doesn’t only have to keep track of the particle positions and velocities, but it has to compute the gravitational effects of every mass (and there can be quite a # on higher levels) on every particle on every frame.

However, I have a few ideas:

  1. Rather than perform those calculations at every frame for every particle, simply make an in-memory map of the combined gravitational field. A particle would just need to refer to the map, depending on its current position, to see how its velocity vector should change. The map would be updated with every mass placement. One potential problem - added granularity to the simulation. It might result in less predictable behavior, which would kill the game. Of course, I can’t be sure until I test it. Also, I’m not sure how long updating the map would take when a new mass is placed.
  2. Limit the # of masses. Not sure how this would affect the balance of the game. A well played level shouldn’t need more than a handful of masses. However, sometimes those extra ones are necessary to cancel out the effect of a badly placed mass.
  3. Simply allow more particles in the system, which would limit the lower-end machine that the game could be played on.

Also, that screenshot you posted previously is hilarious! I wonder: should the game prevent such serendipity? Or is it okay to sometimes have that kind of thing happen?

#18
  1. This would probably work. Since the masses are not moving, the map would only be updated infrequently. Even if you take a few cycles to update the map, to the plyer it would just look like the particles are settling in on the new field.
  2. No, I think the current number of masses is ok. Maybe reduce a couple, but overall it is nice to have them for emergencies.
  3. Instead of this, maybe have each emitter only emit at a certain point. So if you have say 6 emitters, then within 1 second, each would only produce 1 particle at a certain appointed time. The times would be 166, 333, 500, 666, 833, 1000 miliseconds. So white would be at (166, 1166, 2166, …), yellow at (333, 1333, 2333, …) etc… So you guaruntee even particle flow and limit the total particles still.

No. I don’t think it is necessary. The chance of it happening is pretty small. And if it does, it is like a bonus. Most of the time I don’t even get 1 emitter pointing at a consumer.

#19

Source code posted at:

http://www.curiouskangaroo.com/4k/gravitator4k/G_java.txt

under GPL.

Please let me know if you make any changes, and I’ll make them available for all to enjoy.

I’ll probably make mods at some point in the near future, as I get time.