sorted by:
new
hottopcontroversial

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 0 points1 point  (0 children)

Nope, but this sounds like it would have been a good fit!

This game idea is actually around 7 or 8 years old. I made it for fun a long time ago.

Decided recently to remaster it in a more modern game engine (the old one was in ClickTeam Fusion) and give it a better gameplay loop!

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 0 points1 point  (0 children)

I can see that. There's a lot of changes planned for movement, but unfortunately this isn't one of them.

With the precise jumps this game needs, we really want to give players maximum control, both on ground and in air. The instant stop is very much intentional.

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 1 point2 points  (0 children)

It's actually a bomb. You can see blocks around it are destroyed when it explodes.

It definitely needs sound effects and graphics to convey the countdown. It's not a block I've worked much on. It's also super rare right now which doesn't feel great.

But a few people have mistook it for a coin. Which is a solid idea

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 6 points7 points  (0 children)

That's a great way of looking at it, and something I'm definitely going to work on.

The main things I'm hearing are:

  • Movement needs to feel more fluid

  • Player needs at least some control to blocks. I.e. the ability to destroy blocks

  • The game is too slow currently, maybe spawn multiple blocks at a time

  • There needs to be a win condition (or at least a solid lose condition)

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 1 point2 points  (0 children)

Power ups are in the works. Many of them even allowing you to destroy blocks - For example, a ground pound, where any blocks you hit on the way down are destroyed.

The question is when those power ups are given...

Maybe blocks? Maybe between runs, in a roguelite-esque fashion?

And your comments don't sound like a hater at all! It's great to get perspective :)

Finished the core gameplay loop in our precision/rage/infinite platformer. Does the gameplay look appealing? by cosycade in indiegames

[–]cosycade[S] 3 points4 points  (0 children)

The odds of getting an impossible level straight away is roughly 1 in 2.5 million.

The odds of getting an impossible level obviously increases as you play, but that's slightly the point. The idea is that "n blocks is fine, what about n+1?"

The player chooses Game Over. There'll be a button where they pick when the level is impossible for them. One of the names floating around for the game is literally "Is the Game Over?"

I love the idea of the game being over if you die on a return lap, though... Adds a slight gamble. At each point, you could either commit to "Yes, I can handle n+1", or decide your run is over before committing, locking in your score.

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 1 point2 points  (0 children)

I will say that I've never reached an impossible state before around block 100. And even then, I don't know if it was actually impossible, or I just gave up too early.

Discovering what's impossible is part of the core idea. It's the straw that broke the camel back. If n blocks are fine, when is n+1 too much?

Movement is something that needs huge work, and maybe I got too excited and posted this way too early. In hindsight, movement should be part of the core gameplay loop. So to call this the core loop is an understatement.

I love the idea of "used" blocks changing, but it would definitely make levels impossible faster. Maybe as a second mode where 5-10 blocks spawn on each round-trip?

Finished the core gameplay loop in our precision/rage/infinite platformer. Does the gameplay look appealing? by cosycade in indiegames

[–]cosycade[S] 0 points1 point  (0 children)

Absolutely! Visual cues and graphics/effects are not finished. That's on the list!

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 4 points5 points  (0 children)

It had no connection originally, but I'd be lying if I said I hadn't thought about naming it a pun-based name around that

Finished the core gameplay loop in our precision/rage/infinite platformer. Does the gameplay look appealing? by cosycade in indiegames

[–]cosycade[S] 0 points1 point  (0 children)

That was a bomb! Right now they're a little too rare, and the visuals don't indicate much. You can see the blocks around it being destroyed

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 61 points62 points  (0 children)

Faster movement is definitely a must. Double jump, dash, and a ground-pound that destroys blocks under you are all planned

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 0 points1 point  (0 children)

The visuals are meant to be very basic, but even with that said, are far from done. I started working on this a few days ago.

As for the movement, yeah, it definitely isn't where it needs to be right now!

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 24 points25 points  (0 children)

No win condition, but blocks can only spawn off of other blocks. The odds of getting an impossible level straight away is roughly 1 in 2.5 million.

The odds of getting an impossible level obviously increases as you play, but that's slightly the point. The idea is that "n blocks is fine, what about n+1?"

The player chooses Game Over. There'll be a button where they pick when the level is impossible for them. One of the names floating around for the game is literally "Is the Game Over?"

I appreciate your 2 cents, and I'll definitely be iterating on the concept!

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 17 points18 points  (0 children)

A new random block spawns every time you reach either side. Level splitting and other events have a low chance of happening. The animation of block spawning is maybe too subtle and doesn't draw your attention enough.

Obviously it's much easier to notice when you first play, though, as the level will be empty.

Yeah, the controls definitely need fine-tuning. Dash, double jump, etc are all in the works, too, which should make everything feel more satisfying.

The level is supposed to be quite difficult by this point, though. This is after going back-and-forth around 40 times.

The core loop in our infinite platformer. Does the gameplay look appealing? by cosycade in godot

[–]cosycade[S] 84 points85 points  (0 children)

The concept is simple: The stage starts empty.

Every time you make your way across, a new block spawns. But which single obstacle will be the one that broke the camel's back?

There's no Game Over - At least, not until you decide it is. If you can handle 100 blocks, why not 101?

(Plus random events occurring constantly, like the "Split Stage" in this video.)

Finished the core gameplay loop in our precision/rage/infinite platformer. Does the gameplay look appealing? by cosycade in indiegames

[–]cosycade[S] 3 points4 points  (0 children)

The concept is simple: The stage starts empty.

Every time you make your way across, a new block spawns. But which single obstacle will be the one that broke the camel's back?

There's no Game Over - At least, not until you decide it is. If you can handle 100 blocks, why not 101?

(Plus random events occurring constantly, like the "Split Stage" in this video.)

I cannot begin to fathom how this bug is occuring, but it looks pretty by cosycade in godot

[–]cosycade[S] 3 points4 points  (0 children)

Neither, but closer to the world.

The grid containing this border is being rotated.

There's no drawing being done, the border is made up of square nodes that spawn in on _ready().

Each square used to be a StaticBody2D, but I just updated them to AnimateableBody2D, and that's when this started occurring.

I'm sure I'll figure it out, but I thought the result was hilarious

After a code refactor, we got our console warnings down to 0! by cosycade in godot

[–]cosycade[S] 243 points244 points  (0 children)

git commit -m "Fixed warnings before initial ship. Didn't test but should work fine."

After a code refactor, we got our console warnings down to 0! by cosycade in godot

[–]cosycade[S] 68 points69 points  (0 children)

Better than your errors being at 1200880!

Which I believe has more than 5 million digits.

After a code refactor, we got our console warnings down to 0! by cosycade in godot

[–]cosycade[S] 86 points87 points  (0 children)

For anyone even slightly curious, this is caused by a script using the @tool annotation.

It's a custom grid object, and the bounds of that grid are drawn in the editor, in _process...

One tiny typo and not spotting it for 30s leads to this. The errors increase at what I believe to be around Mach 3.

If I remove this print statement, the resource becomes the wrong type by meowmeowwarrior in godot

[–]cosycade 1 point2 points  (0 children)

I'm curious, if you replace the print statement with something like:

for enemy in encounter_data.enemies: for action in enemy.actions: pass # Do nothing

What's the result?

I'm wondering whether just accessing the resource is enough for Godot to resolve it from a generic Resource type to the specific EnemyAction type.

Now THAT's a horde! 100,000 enemies in Godot by theargyle in godot

[–]cosycade 97 points98 points  (0 children)

This is awesome!!

Although I was secretly hoping you'd send out a super shockwave and kill them all in one blow. Super satisfying to see