Show HN: I've been making one HTML5 game per week. Here's my 10th game

It's pretty good for a week of work. Though there's a difference between being challenging and being annoying. Many of the level design elements could be classified as a "dick move." An example would be not making it clear the goal is to collect all the coins until after the player has bypassed some of them and reached the end.

In general the controls are too sluggish. It's as if triple buffering is enabled, or maybe quad buffering. If you're at a university, you should try to borrow a high speed camera and measure the time difference between when someone presses the spacebar vs when the character starts to jump. I don't know if it's a Chrome thing or what, but I fell off cliffs several times due to the input delay.

The gravity could be better. I'd recommend spending some time with Cave Story to get a feel for how to make gravity really work in the player's favor, rather than against them. In general it's a bad idea to make velocity strictly linear. Some acceleration adds to the experience and precision.

A checkpointing system would be good. I can see how most players will give up after getting mostly to the end and then dying. I think you should just restart players from the last point that they were on the ground without dying, that is, the most recent ledge that they were standing on.

It shows promise. If you're looking for feedback about how to advance as a game developer, one step would be to make sure you're not rewriting your entire game engine from scratch for each game. It's excellent that you're writing your own engines rather than trying to use other people's, so be sure to keep doing that. It's important for gamedevs to have an idea of the underlying principles and limitations, and the best way to do that is to write your own engines. I got the feeling that most of the week was spent on the engine rather than iterating on the gameplay or level design though. Teaming up with an artist or a level designer might be a good match.

My current plan is to make a bite-sized game comparable to this at least once a month (it'd be a little stressful to force myself to come up with something fresh every single week) and maybe just experiment with small projects with no plans for completion in between. I also have a long-term project that I'm expecting will take ~2 years, and honestly, sometimes I feel like I've run out of ideas. Taking time away from my main project to work on these little "distractions" actually ends up helping with my main work. I spend less time idly waiting around for a good idea or solution to a persisting problem, and more time solving new, smaller problems that can later be applied somewhere else. Hell, I actually find myself actively switching between tasks every 10 minutes and ending up even more productive than I would be focusing on just one project. Also, I had no real experience with Unity before this game, and just taking a couple of days to force myself to learn it opened some doors for future big projects.

In short, work on tiny projects whenever you find yourself doing nothing. You might end up more productive or just happier knowing what you're capable of.

That said, this one is frustrating. I feel the keys are off. I like to run before I jump and in some areas, it's not possible because the responsiveness of the keys just isn't there. It takes too long for my guy to jump after I press up. Also, it seems like you're possibly doing your left/right code in a way that gives left priority. If I press both left and right, my guy goes left. I feel like he should stay stationary in that situation.

Other than that, I like the gameplay, tutorial text that's part of the scene, the sounds and music. I really like the cube slanting to show motion, too. Clever.

Keep it up!

http://gamasutra.com/blogs/ThomasPalef/20140225/211663/What_...

Worth it especially for the following superb link:

http://www.gamasutra.com/view/feature/130848/how_to_prototyp...

I think the basic level design and polish steps are fairly well done. Even the sluggish controls (as a number of people have pointed out) feel more limited by lack of engineering time than your understanding of what feels good, and I would guess that through some rigorous testing and closer scrutiny of your code that could easily be fixed.

However, I think you exhibit some game design anti-patterns. I am referencing Zileas' List of Game Design Anti-Patterns[1], that I think game designers should reference more often until it's a quick checklist whenever they design any game.

Most notably I think Dark Blue succumbs to "False Choice" and "Or We Could the Player."

[1] http://forums.na.leagueoflegends.com/board/showthread.php?t=...

Admittedly, only a couple of them truly qualify for that title (annoyingly difficult gravity games with stupid simple controls), but I think they all adhere to the same theme - extremely simple game ideas that are nevertheless compelling.

In the Atari-NES era, technical constraints forced this style of game design upon developers, and they (well, some of them) still produced compelling games by focusing on the details of these simple interactions. There are admittedly somewhat similar constraints on this particular canvas (ahem) but I believe the tools have evolved so much that you can spend a lot more time on the mechanics, rather than fitting it into RAM (hence, 10 rather polished 8-bit style games in 10 weeks).

I think it's good to get back to basics. I played all 10 games, and I enjoyed it (though the typing game was downright cruel; it's amazing how difficult it is to read and understand a misspelled word, then type it misspelled, let alone the gibberish). Well done.

- you need to fix the gravity so it doesn't feel like it's on the moon. I used to get the gravity wrong as well, but it makes for so much more fun and snappy gameplay when you get it right (or actually, a bit more right, cause nobody really jumps that high anyway).

- assuming your game logic goes a little something like, if the player is standing on something solid, they can jump: instead doing that, give the player a few frames (3-5) of leeway while they still can jump even though they just walked off a platform ledge. it's a very subtle thing, and if you don't pay attention you won't see that most platformers do this, but it makes all the difference in gameplay (if the player feels like they would have totally made that jump, but drop off the ledge instead, it feels like their character just stumbled or something).

the last one is also based on one of the golden rules of gameplay: try to make the game behave as the player wants, which is not always necessarily exactly how the controls are input.

(the following stuff is not really critique of your game but some things to keep in mind as you continue)

similar tricks involve making the hitboxes of "good" objects larger than they actually are, and the hitboxes of "bad" objects smaller (player thinks: "phew! cool! I barely missed that enemy!!"). btw Flappy Bird subverts this rule, which makes part of its interesting frustratingness, but as always you gotta know the rules before you break the rules.

and remember, you can always make your levels harder, if you think such tricks make it too easy on the player. you'll find that in such cases "harder" translates to "challenging" instead of "frustrating".

good luck!

A colleague of mine made a similar type of game a while ago, this reminded me of that.

http://www.tyasdev.com/MrBandana/

I didn't actually like the explanations throughout the first few levels: sometimes it would be nice to figure things out on your own; feels like you rob the player of the reward for completing the level when you explain it to them before letting them figure it out? Especially since they can restart pretty quickly: case in point, let them fall into the red and die early on rather than explain it?

Hope I don't sound overly critical, as its a cool game and I appreciate you posting it.

Critique-wise, the low end of the variable jump height is a little high, and if the game lags it messes up the physics (e.g. in the first tunnel of the last level the player stayed up against the ceiling longer than usual, missing the platform).

Try this,

1. open Game#10 in chrome

2. Open the web inspector

3. Go to profiles, choose Record Heap Allocations, and start

4. Now try playing the game. You should be able to jump farther and higher. In some levels, even overcome multiple climbs in a single shot than otherwise

Also notice kind of slowdown overall. But not necessarily a drag since all the key events are still taken in seemingly the same speed

So why is this? Or is it another Chrome one-off?

Because of your website I tried making my own simple game with Phaser and found it to be very fun. For someone who'd never programmed a game before, it was interesting to see how everything comes together. Just a simple game was very fulfilling to me.

The progression in difficulty seems just right. This is exactly what casual gaming should be like.

The jumping mechanics reminded me of "air control" in strafe jumping in Quake 2. Can you tell I haven't played games much lately?

Love the music. I have had the tab opened for a few minutes now that I'm done playing just listening to it loop through.

I'll also take the opportunity to plug my HTML5 game collection:

http://yangcanvas.com/arcade

I would be interested to know what you used for collision detection (If anything).

Curious why you chose HTML5?

http://i.imgur.com/xKTvH81.png

:) great game. i enjoyed it! very similar to super meat boy