I've been making good progress with my jumping game, with the core mechanic now mostly done (…although physics were harder than expected to set up).

The next steps will be to draw final art… and more importantly, balance the difficulty. That difficulty part is quite tricky, as a good level design should be able to avoid "impossible situations" where deaths are forced. How could we do that yet keep the game hard, and even make it get harder with time? I see two main approaches:

1. Keep the levels procedurally generated, and do some clever coding to make level generation harder & harder without being unfair ;
2. Use pre-made "level chunks" of various difficulties, that would be playtested by hand.

Solution 2 would be too time consuming & unexciting, not mentioning I'd need to playtest again from scratch if I decide to tweak physics constants… So yeah I'll stick with fully procedural levels. To quickly get something I can ship, I've wanted to avoid being too concerned about imperfect levels: a trick was to introduce an "oxygen management" mechanic. The way it helps with level design is that it lets players do (limited) air jumps, which means that even if there's a huge hole in the level it still leaves a chance to survive.

Now, for the ideal solution…

The main idea I've had for "100% solvable" level generation is to place an AI player below the screen, before rockets are even spawned, that "plays" exactly like the player would. It would randomly decide to swap sides & jump, the trick being that the AI also decides when it lands: When reaching one of the 3 "rocket lanes", he'd be able to trigger rocket generation. A rocket would then magically appear right where the AI is, so we're 100% sure that the game is playable :)

We could then adjust the difficulty in various ways:

• Especially in early phases of the game, filling voids with some additional rockets would help make things easy and the "AI path" not too obvious
• The AI could play with increasingly tight timing
• The rockets could be made shorter, or positioned so that there's little margin for error

I'm not sure how widespread this technique of using an AI is, but it may be fun to try. To be continued…

Having a blast coding this weekend. Hard to believe that the simplest things could be so hard to code.

Like trying to get bullets to fire on a consistant velocity. That took me a good few hours to figure out. Stretching my math muscles was a welcome change.

Not sure how to post pics or vids of my progress, but I just posted what I've made on my Twitter account! Then you'll see the meaning of my post's title! hehe.
https://twitter.com/SnowFoxGames/status/1082080890178551808

This is a really interesting one! Gonna have to shift gear in my brain and try and design something with different goals than I usually have!

This should be fun, going to try and push myself to build this for mobile because I've never made a mobile game. Probably just Android because that's what I own. Mobile is perfect for the hyper casual genre so we'll see how it goes.
No ideas yet so I better get brainstorming, good luck everyone!

Just took a look at the theme for this months jam. I don't tend to play many Hyper-Casual games, but I'm familiar with my temple runs, flappy birds and such. I think I already know what I want to do, and it stems from a project I did way back when I was using GameMaker Studio.

I'd created the basics of an endless runner, with moving platforms where a player had to jump from platform to platform to gather coins. As the player score got higher, new obstacles would spawn like turrets on platforms and rotating saw blades.

With GameMaker, I managed the basics, but never finished it and never got to add the obstacles I wanted.

That being said, I am currently using Unity, so I basically have to start from scratch.

In a month though? Hope I can pull it off!

I have tried to think about any simple but fun and mobile-friendly mechanic I could find, and here's the result:

Story: It won't be told explicitly (except maybe through the game name), but I always need a story to get me engaged in my projects. Here, humanity is escaping Earth due to an imminent disaster. Thousands of rockets are launching into space, except you have been forgotten behind :D You had the brilliant idea to just hop on a launching rocket, so now let's just try to stay alive…

Gameplay: It's simply about staying on screen for as long as you can, by jumping between rockets that scroll at different speeds. Maybe you just you can't stick to the rockets correctly and are constantly sliding along them, forcing you to jump to something else before you fall off. Anyway the controls are just:

1. Hold touch for the right time to jump on a neighbor rocket
2. Tap to switch sides of the rocket you're on
3. Use 1 & 2 to stay alive as long as you can

I aim to build this both for PC and Android. And will probably prototype this during a One Hour Game Jam.

I've been beavering away on my Feedback Fortnight game over the last month, making steady progress. I put up v1 a couple of weeks ago, and today I have a second version ready. There's plently of changes, bugfixes, and refactoring. I got an idea from Dr Laguna's feedback: you can now upgrade your spells after you defeat certain wizards. Adding this feature required refactoring a whole bunch of code as the various spells were all hardcoded and never meant to be changed in its original version!

I've also added more music and gone through the sprites with a fine comb - there's enough space to add another enemy/spell, and I would love feedback on what would be a cool addition to the game!

Missing things and known bugs:

• win screen, intro screen and in-game tutorial
• AI - still random
• units with haste sometimes jumps back while moving (display bug)
• non-unit spells sometimes appear to hit things a bit far away (bug, but might leave it like this - it's a hassle to get right)

Things added in v2:

• multiple maps and crystal tower configs (and countdown on the crystal towers)
• hard mode (and super hard mode) options (press enter before your first battle to try them out!)
• non-unit spells
• spell upgrade functionality
• units are now using their wizard's colours
• friendly fire for non-unit spells (beware…)
• a new html wrapper as chrome won't let you autoplay sounds anymore

Welp, November was an interesting month. Participated in Nanowrimo and got away with 23000 words. Less than half the goal, but no matter. Pretty happy I was able to churn that much out in that short time.

December has been the month of relax, especially now with that holiday right around the corner.

It's time to get back into game dev. I imagine my coding skills are a bit rusty after such a long hiatus, but I hope it will come back to me in time for the next Kajam.

I'm looking forward to stretching my coding muscles once more.

Hey there,

I am really looking forward to this Alakajam Feedback Fortnight event! Unfortnunately I missed the first FF event, but this time I submitted an entry! For LD41 DevilLime, xXBloodyOrange and I worked on a mashup between a Tower Defense and a Clicker game: Grantchester Meadows which is now awaiting your feedback!

I am also looking forward to play your entries. I will try and give detailed feedback.

I participated in Ludum Dare 43 recently, and came up with this mess: https://ldjam.com/events/ludum-dare/43/the-greater-good

A quick update on my A.G. Hope update towards a sellable game (now renamed to Modular Hope).

I think I've spent roughly 8 hours on the game so far, and it's been mostly dedicated to rewriting the controls and physics for the game. What made things a bit slower is how I've been trying to take advantage of "data oriented programming" patterns that are making their way into Unity good practices.

I think I have a good base now for managing & structuring those modular spaceships, the current step being to implement docking on top of it. My first attempt hasn't been too great :P I attempted to optimize things by creating a single, large circle trigger on each room to detect other rooms within docking range… Except not only I have a little direction detection bug (see below!), but I just realized that in fact it wouldn't behave correctly in all cases. What I need to do is put a trigger on each of all 4 sides of the room.

To be continued…