Spiderball4k [updated, new map]

Contests 4K Game Competition - 2008
#21

Replay!
29 3a2 18b 2 3b 388 138 1 52 386 147 2 6a 39c 143 1 7e 3bf 156 2 90 3de 15e 1 a7 401 167 2 be 424 16d 1 d5 42a 173 2 ea 452 174 1 102 477 173 2 117 496 171 1 12c 4b4 170 2 141 4d2 16d 1 157 4f1 16c 2 16b 50d 16d 1 181 52f 16e 2 199 556 16e 1 1ae 574 16c 2 1ca 58c 16d 1 276 5c7 2f5 2 27b 5c8 313 1 28c 5cf 373 2 2a5 609 411 2 2c8 5e0 50e 1 2e0 540 451 2 2ef 542 464 1 2f5 540 470 2 338 466 47b 2 341 450 47b 1 384 3b3 469 2 389 3a5 46a 1 3bf 303 46f 2 3c4 2f5 46f 1 431 2d1 47e 2 434 2ce 47b 1 46a 2c7 58f 2 46b 2c5 58e 1

Wondering if you did it that way? :stuck_out_tongue:

#22

I’d suggest trying with quadratic, or cubic curves to get rid of all those hard edges - it might even allow you to reduce the poly-count on some of the levels.

#23

Hm. That’s an interesting idea… It might help poly-count for some levels but given the fact I’d need control points it might also increase it. As it is, the level’s rendered using fillPolygon (gasp!) which is more or less the reason it’s so slow, so it’d be a quite big change to the code. I’ll give it some thought :slight_smile:

EDIT: Cool stuff, all those maps added to the site CaptainJester! Keep it up! :smiley:

#24

I have had a thought which might help shrink the sizes of embedded levels.

Instead of storing each vertex exactly, why not attempt an approximation?

proposed algorithm:

level creation side:

  1. choose a random seed and set a Random instance to that seed
  2. generate n random pairs doubles. where n = the number of vertices in the level
  3. multiply each pair the max width and max height of your playable area
  4. compare each pair to the corresponding vertex. Maybe using the squared difference.
    4a. if the total squared difference of all the pairs is currently the minimum then store the random seed.
  5. repeat 1 until end critera ( number of loops, or the error is below a pre-determined level)

game side:

  1. Create a Random instance set to the stored random seed.
  2. generate n random pairs doubles. where n = the number of vertices in the level
  3. multiply each pair the max width and max height of your playable area
  4. these pairs are the vertices and thus use them as usual.

With larger levels with more vetices you might need to break it up so each random seed can produce a max of say 10 pairs otherwise the error might be too large and the result not representive of the level.

#25

Hm… that’s a very interesting thought. It might slow down the level editor process some, but it should decrease map size and map loading times. It has a rather unexpected side effect; I’ll explain by first explaining the current format.

A map currently looks like “hexstring,hexstring”. Both strings are divisible by four. Every four characters is a coordinate pair that ranges from 0-255 x, 0-255 y. These are then multiplied by 16 ingame, to increase the level size. Thus, I’m sacrificing precision to decrease level size.

The first string consists of n pairs of coordinates for the polygon, then two pairs of coordinates for start and end. The second string holds all the moveable objects on the map.

A side effect of this storeage method is that any coordinate in the level editor is rounded down to the closest multiple of 16. This allows for entirely straight lines for the polygon, which in turn lets you make lines with no width (that you can pass) to smaller polygons within the polygon. Due to how polygons behave when its lines cross each other, the new polygon will count as “outside” the first one. The collision checking in the game is done using a simple Polygon.contains(int x, int y), and so my method allows for caves with obstacles without having more actual polygons.

Of course, it’d be better to support several polygons, but as it is I’m only checking whether the player is outside the polygon or not. With more polygons, I’d have to check whether the player is outside the first polygon, and inside the rest of them, so I’d have to keep track of polygons seperately. This could be replaced by subtracting the main polygon from an Area, but that would instead decrease performance.

</long story>

The point is, if I changed to random approximation of maps I would most likely lose the ability to have straight lines, and thus the ability to fake having multiple polygons… I think? Currently, the maps compress well, and each map tends to stay at some 20-30 bytes. On the other hand, I have decided to only have small maps in the game, so randomization would help by allowing for larger maps… It might well be worth it. I’ll give it some further thought :slight_smile:

#26

This game is so addictive!! I hope you can fit it into 4k. It reminds me of the 4k submission bullets a little. It was awesomely rewarding to finish the game, and i just wanted it to go on forever. Has the same sort of addictive fun as Portal!!

#27

Thanks!

It’s no coincidence that spiderball feels a bit like bullets. I made both games, and I’m using a modified version of the bullets map format for spiderball game, meaning some elements are similar :slight_smile:

#28

Very neat game, it seems the quality of those 4k games is going up! This is just great addictive fun, even if it were 40k :slight_smile:

#29

Wow, this is a lot of fun, I can’t believe I haven’t tried this before now. Excellent game, good job.

#30

Thank you, thank you!

New version up. I’ve added Z and X as keys representing mouse1 and mouse2 again as an option for macs (Ctrl+mouse still works too). Also, one new map (lvl 10 - tricky one!).

#31

It’s damn cool! And I just finished the last level! 8)

#32

Jeebus this game is like impossible.