Last Worm Creeping - enhancing the gameplay
-
Because I could not resist to the Game Jam 8 I got now another project. I had some things in mind like "real rainbow colors" and a more addictive gameplay. But I am still not sure, if I should add the whole game menu features - I like the click and go style too.
Download code: NXK2L5FDN8
-
-
-
When I started to implement this worm game I thought: "take a simple approach of implementing, make it quick, and then just enjoy the game" I started with shapes: drawing shapes is way too slow. So, I switched to convert them to sprites: oh well, checking 10000 collisions in one loop is a bad idea. Never thought a worm with 250 sprites, 80 food units, 30 enemies will take so much efforts to make it work. With the simple zone approach (just dividing the screen into 16 zones, for example), I could remove the exponential order, but I still got stuck with 9'000 comparisons. This ruined the fps again. This i my last approach: (probably before I get back to simple sorted lists again ;-) )
-
This must be how NASA tracks space junk..
-
-
Appendix, what has changed:
- background: gradient and worms that fade out, instead of plain color
- performance: the speed of the worm was drastically slowing down above 100 body elements. Filling all sprites into a quad tree data structure, allows, to make only collision checks in certain areas, where other objects are present. By using a tree it was possible to make collision checks at 30 fps having 80 food objects and 260 body elements.
- the music is playing during the game
- nicer shadows
- I finally made my own font ;-)
Major issues:
Quad tree implementation: to build up the tree I need a recursive function and I think we could gain speed, if I could pass arrays within arrays by reference. Or references to arrays within a sprite (e.g. when I use custom sprite attributes like "sprite.attribute" and use an array as its attribute).
Meaning: it is not possible to have a spriteTree[5][5] and passing spriteTree[3] by reference and expecting that the global spriteTree will change. But I think that's by design, its not C programming. ;-) and should not be.
Building the tree eats up most of the performance. I could try a final approach, with a flat array and only passing indexes during building the tree. -
Update 15.12.2021 shared!
- proper, single SFX channel (for playing samples only) to not disturb the music
- improved music fadeouts when the level has been completed or the game is over
- volume was higher after restarting the game
- game over and next level jingles were suppressed
- first note of the music theme was suppressed
Bug report: https://fuzearena.com/forum/topic/1862/playaudio-and-playnote-do-not-play-well-together/1
-
Update 28.12.2021 (pending)
Worked on the gameplay and memory cleanup:- added the worm panel, knowing, if you are the longest worm helps for the gameplay
- made the logic behind the size changes clearer: +5 points = +1 size unit, visually the worm only change its length, after +2 size units
- worms spawn at the borders, means you cannot be hit immediately after a level start (as long you are not lingering along the borders)
- on the next level, you just continue from the current position and are not placed again into the middle
- the food stays, when entering the next level, so you can continue savage the remains 🤪
- tracked down all memory leaks 😮💨 (the game sometimes crashed after 20-30 min playing)
- completely removed the Freelist data structure implementation, it should have been a workaround to not being able to shrink and resize arrays, but it was useless, when not applied to all sprites, and all sprites would have to be wrapped into arrays.
- enemy worm size increases now correctly when a level has been completed
-
Wow, from a simple gamejam entry, this is becoming quite something!
-
Amazing work, @spikey!
Can’t wait to try out the newest version! -
Wow, that theme song is so good!
