diptoman

LD 41

Bullet Hell Patterns

6.png

So this has been my 3rd bullet hell entry for a game jam (first in a LD) - so I thought I'd share how I generate patterns easily. Note that this is for generic patterns - there are specialized patterns (even in this game) whose behavior you'd have to program separately.

Step 1: Have a spawner class which spawns bullets.

Step 2: Create some common variables for every bullet type:

InitSpeed: What speed the bullet starts with

FinalSpeed: What speed the bullet ends at

Deceleration: The rate at which the bullet decelerates.

DecelerationDelay: If there's a delay from when the decel starts.

NumberOfBullets: Number of bullets created in one round

AngleVariation: The angle between two bullets in terms of direction

NumberOfRounds: Number of rounds in one burst (one burst is considered firing once).

TimeBetweenRounds: The time between two rounds.

RateOfFire: The time between each set of rounds

SpawnerRotationRate: The rate at which the spawner rotates

NumberOfSpawners: The number of spawners, equally spaced in terms of angle.

Step 3: Program the spawner to spawn based on just those variables - should be fairly easy to do.

Remember, if you're creating a more danmaku-like game, make sure your bullets have deceleration and a minimum speed. This was used in this game.

And voila - by changing just these values - you can get a lot of variations! You can set these variables to vary based on the current level too to make teh game progressively harder. You can try out the effects in our deckbuilding x bullet-hell entry!

Thank you all!

MTS.gif

A word of thanks to all of you who've voted and left all the good comments on our bullet-hell/card game mashup - there are some great and insightful feedback in there! Good luck to you all for the results!

LD 42

One final push!

Might actually complete the whole thing this time without completely exhausting ourselves.

Mindblocked.gif

Mind blocked?

Is your mind blocked from all that jamming?

Then now is the perfect time to block it even further with our puzzle entry - Mindblocked!

Mindblocked3.gif

I'm about to start playing other games now too, all suggestions are welcome! :)

Designing and pacing puzzles for jams - some thoughts from experience

Mindblocked2.gif

I've made a couple of puzzle games for jams before this (LD42) entry - LD40, LD36, LD27, GMCJam13, GMCJam9 etc.

Generally - this means creating a bunch of puzzle levels in a very short span of time, and you don't particularly have time to put much thought into pacing the puzzles.

I generally follow a rule of having the last 2-3 levels include every mechanic in the puzzle, while the rest of the levels introduce new puzzle mechanics spaced evenly. Just to pace things out, and not overload the player with information. My first 2-3 levels almost always are extremely simple solutions, to make sure the player gets your base mechanic (plus, it helps you pad the number of levels ;) ).

  • When making the puzzle, I generally start by placing the goal and the player first (if there's a clear goal - if not, by deciding the end condition).
  • A second step normally would be to decide what I want out of that level - do I want to reinforce an idea to the player? Do I want them to figure out a certain mechanic can be used in a special way? (For example, the shown level is explaining the various ways teleporters can be used, through gameplay. I force the player to use a teleporter multiple times - emphasizing that they're reuseable).
  • Now I imagine a path to that end goal - which almost always never stays the same by the end of designing.
  • I start designing in reverse. Now that I want them to follow this set of directions, what do I do to make players follow this?
  • I start placing pieces which will help towards that goal.

That's it! If you want to see some of that method in action, you could try out our game - Mindblocked!

Mindblocked - Were the minds really blocked? A Short Post Mortem

Mindblocked3.gif

First things first - thank you all for all the super positive comments and the 60+ ratings on Mindblocked! Please do give it a shot if puzzle games are your thing!

This is my 20+something-eth game jam, so at this point most of the common jamming things to learn - we're generally aware of (time management, teamwork issues, working in different timezones, scoping etc.). I mostly want to talk about the things which went right for us with this jam.

  • The idea - We use the theme in both a negative and a positive manner. Running out of space here is not entirely a bad thing, because in the end - the reduced space (created by your own movement) helps you navigate to your target and is a core part of the mechanic.

  • Number of Mechanics. Generally not a good idea to have a bunch of mechanics in a jam game - but these were largely easy to implement considering how the base code was implemented - which kept the game fresh over the levels. (And we had more options to make things!)

  • The Difficulty Curve. A general rule of thumb when introducing mechanics and ramping difficulty we followed here was (Simple mechanic intro) -> (Level utilizing that mechanic better) -> (Level utilizing that mechanic in conjunction with other mechanics better) -> (Simple mechanic intro) -> ... (and so on till all the mechanics have been introduced, then you just keep making harder levels). The curve somehow accidentally worked out pretty well too (the artist made a few levels, which I didn't get to test before submitting - I just told him to make those "middle of the road post-intro levels" for some of them). It also helped that we had a lot of mechanics to follow this curve properly.

  • Resolution and scaling. The actual game is tiny, and in pixel art. This means we could do integer scaling properly, because it would mostly fit in any window size. I start the game by scaling it up an integer number of times to the max amount possible at first - but let the player switch to fullscreen and smaller windows too - whatever works for them. This gives more flexibility on how the player wants to view and play the game.

  • Something that did not go right was a few timing issues. A lot of the game uses delta timing for movement - but some parts uses step timing, which means a lag (sometimes in HTML5) can potentially screw up the synchronization of movement (happens very rarely, but still). That was oversight on my part when programming.

  • No original music. The composer who usually jams with us was busy on the weekend, so we ended up creating a few SFX, but had to find background music - which took out some of our time from other things (A huge props to Ozzed for having a wonderful collection of music up there).

That's it for LD42 folks! See you next jam!

Also, shameless plug - we made a game for the GMTK Jam this weekend too (because we clearly want to burn ourselves out): Check it out! LazyPlatformer.gif

Ludum Dare 45

Armadone!

Sleepless nights and bad headaches later - Armada is done! We made a dodge-em up/shooter where you build your own armada over time to invade planets, starting with nothing but a lone mothership.

ArmadaGIFCompressed.gif

Link To Entry

Heading to bed now. Will start playing all these beautiful jam games later on!

Cheerio and great work everyone!

Armade it!

Made a gameplay video of our unconventional armada-building scrollshooter to show off!

https://youtu.be/FCNfdT689F8

And a short gif to accompany it!

ArmadaGIFCompressed.gif

We have enough ratings now but would always love more! Play Armada here!

Will make a more detailed post-mortem sometime later as well. Meanwhile, I'm having a blast playing all these other lovely games!

Ludum Dare 47

Satellooping 'Round

I realized this is my 11th LD participation with the same people! Give our entry a shot if you like lolling around on a satelloop!

Screen_4.png

Onwards to playing some of these awesome games!

Satelloop Dev Recap 1 - Ideation

SatellopGif.gif

We thought about a lot of stuff for this theme - because it had endless possibilities, and a lot of our older jam games would fit this too. The first thing that came to our mind was an older jam game we made on a similar theme - called Dante's Inferloop: ezgif.com-video-to-gif.gif That was a game about running in a loop till you get the answers right at the end - a genre mashup.

We considered about having something like that (a sequel perhaps?), but pressed on for other possible ideas. There were 3 ideas we zoomed in on:

-> A puzzle platformer about using loops you create on death.

-> A block coding puzzle game where the start blocks always end in a loop, and the challenge is to fix it and get the desired end goal.

-> A game which somehow involves this very cool looking satellite loop thing my art dude drew up.

After a lot of discussion (well, not really, it's just 2 of us) - while we liked the 2nd one, we had doubts on how feasible it was in the time frame. We really really liked the satellite loop structure, and decided to build a game around that. I mean look at it! Screen_4.png

So we thought about how we can build around it. We discarded a flat out shooting game - shooters are always a last resort, and we thought along the lines of dual purpose design - how we can use the same mechanic for multiple things. We used it to ensure that the asteroids are BOTH your lifeline and your threat, and the drones you use are used for all of collecting, destroying, and repairing. Add in a hook mechanic to recollect drones and add a resource management angle to it - and voila, we get Satelloop!

Some cool games - Pt.1!

Here's a couple of really cool games I've enjoyed so far on my playthroughs!

Purgatory Is A Music Store - Very relaxing experience, will make you feel like a maestro! D1.gif

AirStralian - Super well polished and fun boomerang controlling game! D2.gif

Nirvana - Very cool experience about the "loop" of life and death - with some laugh out loud moments!

And of course - a shameless plug on our game - Satelloop! Satelloop Gif2Main.gif

Looking forward to more awesome games!

Satelloop Dev Recap 2 - More Ideation

Read Recap 1 here!

So, once we've decided to base a game around resource management/some shooting around this amazingly drawn structure, we needed to figure out how to go about the management aspect. 39736.png

Some of the ideas thrown about were: 1. Shoot drones to collect resources. Manually hook and swing around to asteroids/your ship part to repair/retrieve/detonate drones. This was quickly discarded as I did not want to deal with trying to code 360 space gravity and all the shenanigans that'd entail. 2. Shoot asteroids with resourcing drones to collect resources. Shoot asteroids with destruction drones to destroy them. Shoot broken ship parts with repairing drones to fix them. This would have a singular and more intuitive control scheme (Switch drones & Shoot drones) but it was more work on the UI, and we lost a big chunk of the resource management of drone retrieval with such fire-and-forget mechanics. This would emphasize the arcade aspects of the game more, and we wanted to avoid that. 3. An even more simplified version of the above with LMB to shoot resourcing/repair drones (no need for drone switching mechanics) and RMB to shoot destruction drones. This would remove the UI complications, make it much easier to get into for players - but it had the same problem as before - we didn't want the game to be essentially a shooter with some resourcing thrown into it as an afterthought. 4. There is one kind of drone for everything. If shot at an asteroid, it would collect resources. If shot at a broken part, it would repair. A drone can additionally be blown up or retrieved with a hook (RMB). That second part added a big resourcing consideration and tied together nicely with our drone generator mechanic. Now players would actively have to try to save their drones whenever possible, instead of just firing and forgetting. The ideal gameplay would revolve round saving drones in backup from the drone generators, and having your inventory full at all times. We went with this in the end: Satelloop Gif2Main.gif 5. We tried a variation of the above where the drone auto-destructed an asteroid if it's near the ship, but removed that because that took away from the management aspect as well.

In the end, we decided to go with the slightly more complex version of resource management over having it feel more arcadey. We feel the controls worked smoothly, just took a little getting-used-to since most people are familiarized by fire-and-forget mechanics by default.

You can play Satelloop here!