GMTK 2024 Game Jam: Sticky Ships

on

 Cover image for Sticky Ships. It says "Sticky Ships" and has a picture of a space ship flying through space.


tl;dr: I participated with friends in the GMTK 2024 game jam, and we made a bullet-hell game with a compelling ship-part-attachment-and-upgrade mechanic!



The game

We added two mechanics that make this game special.
  • The first is the ability to attach parts of destroyed enemies to your ship, in order to have more weapons and thrusters.
  • The second is the ability to grow to a new size mode when you have enough parts to level-up.

The jam

The theme of the jam was "Built to Scale".

We made this game for the GMTK 2024 game jam. This was created in 96 hours.

We made all the design, code, images, sound effects, and music during the jam.

Screenshots

An animated GIF showing gameplay with many parts attached, many enemies, and many projectiles flying.
Eventually, you have many parts attached to your ship!

An animated GIF showing game of the ship being leveled-up.
When you accumulate enough parts, you upgrade to a larger core size.

An animated GIF showing the ship-level-up animation.
The ship-upgrade animation turned out well!

Retrospective

  • 96 hours vs 48 hours
    • I wish this had been a normal 48-hour jam.
    • They were trying something new this time, and let people work on their games for 4 days instead of 2.
    • Unfortunately, we all mostly still had work to do for two of those four days, so it didn't give us much extra time, and it did give us more stress and sleep deprivation.
  • Difficulties
    • There were a lot of complex systems involved in this game!
    • The part-attachment system has a ton of edge-cases that needed fixes throughout the jam.
    • The modular enemy ability and behavior system has a lot of moving parts!
    • The enemy spawn scheduler is a pretty common thing to add to a game like this, but it's never as simple as you might think it should be.
  • Features that didn't make the cut and design trade-offs
    • Trade-offs for how to handle zoom-outs and showing enemies/parts/projectiles at different resolutions.
      • We ended up going with a x2 image-size difference between growth levels and a x2 camera zoom.
      • I think it would have been fun to play around more with larger zoom changes between levels, so that you _really_ feel like the context of the game has changed and you're in a completely different mode.
        • With the current game, big guys feel like little guys after you level-up. But I kinda thought it would be fun if they felt mosquito-like.
      • I originally wanted to create separate resolutions of each enemy/part/projectile sprite, so we could show the same enemy as the current growth-level size for all growth-levels.
        • This would have allowed us to support leveling-up (and zooming-out) infinitely, turning this into a roguelike.
    • I originally implemented some consolidated global-based configuration systems, but we ended up using distributed scene-based configurations for almost everything.
      • In general, the detached consolidated configuration style is more what I'm used to using professionally. BUT, the distributed configuration style aligns more with the "Godot way" of doing things, and is really what I want to practice doing more (at least for jams like this). :) Fortunately, Zaven has a knack for this style and was able to point me in the right direction.
      • Distributed
        • Closer to scene definitions, easier to track down, and easier to set up quickly.
          • This was definitely a pain point I felt during this jam.
        • More the "Godot way".
          • By this, I just mean that most of Godot's systems seem designed with this style in-mind. They make it easier to do things this way by default.
      • Consolidated
        • Easier to update everything quickly when playtesting and balancing.
          • I _did_ feel the pain of missing this a bit when balancing near the end of the jam.
        • Easier to reference other values when making changes and easier to keep different entities in-sync.
        • Decouples state from code, giving you more flexibility for changing game state in a production environment.
    • I really wanted to add entities from the next level size as random "terrain" obstacles in the current level size.
      • This would have required using a bigger zoom difference between levels.
    • We really wanted to add a boss!
    • We wanted to add gameplay for a third growth level.
    • I wanted to add asteroids, which would have been a simple part that just blocks in-coming damage.
  • Playtesting and balancing
    • I think we hit a pretty good balance!
    • If anything, it should be a bit harder.
    • BUT, the infamous problem of game-jam games is that their creators always make them too difficult, and no-one will spend the time or effort to make it through the game.
    • Our game _is_ pretty easy in its current state. BUT, everyone is playing it through to the end, and everyone is still commenting about how much fun they are having while doing so.
    • So I think the easy difficulty is perfect for this.
  • Sounds
    • This was my third jam with Alden making sounds and music!
    • It's always fun to hear the really cool things he comes up with throughout the jam.
    • We made him learn new things this time with a new game engine (he's used Unreal previously), but he picked it up quickly!
  • Pixels
    • I felt like I had more time to make some fun sprites and pixel animations this jam than normal.
    • In particular, I think my laser and level-up animations turned out well.
    • And all of Zaven's pixel art is excellent, as always!


🎉 Cheers!


This is a simple icon representing my sabbatical.

Comments

Post a Comment