Not sure if you're looking for critique, and giving critique has sometimes been discouraged on HN, but:
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.
> 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.
The first time you see coins, the caption reads "coins are good, take them." Then at the end of the first level, it says "collect all coins to finish the level." I'm not sure how he could be more clear than that, and even if someone misses the captions, it's immediately clear after one failure.
"Take them" implies that they are important, but does not definitively state that they are required. It's like saying in Legend of Zelda "Triforce pieces are good. Take them." It's massively understating the importance of the Triforce, since you can't beat the game without all the pieces.
Let's just leave it at "some people were confused". Because honestly, in terms of user experience, that's all that matters.
I'm not a game developer, but I found the jump key to be slightly inconsistent, specifically pressing jump while running towards a ledge. Whether or not the jump registers seems to depend on how close to the edge you are. The closer you are, the less likely the jump is to register.
I guess depending on what you want out of the game mechanics, you could leave it as is or extend the "range" of a valid jump to slightly beyond the edge (perhaps half the width of the character). I guess some good questions that you could ask are:
- Is it a faster paced game where jumping from platform to platform quickly matters?
- Do you want to focus more on fluid movement and the ability of the player to think about their moves ahead of time?
- Are there any gaps in any level where the jump is nigh impossible without performing a "perfect" jump. If so, is that a feature? (maybe it's supposed to be that difficult?)
EDIT:
I've been looking at the source and I'm pretty sure it has to do with how Phaser checks whether the character is on solid ground or not (body.blocked.down). I'm not too sure how it calculates it (I couldn't understand the SAT.testPolygonPolygon function[1]. If anyone wants to help me with that, I'd appreciate it). I think the tilt of the character when it's running potentially makes it worse too.
Most platformer games actually let you jump for a short time after you run off the edge of a platform. The lack of this mechanic is what causes the jump to feel inconsistent.
I ran into the same jump issue. Playing with two hands (one for right one for jump) seemed to help. Maybe it has something to do with rapid consecutive inputs being lost.
I also found the hardest thing about the game to be figuring out the lag in timing between pressing jump and my character actually leaving the ground. Windows 7, Chrome.
I worked through the fourth level. It took me a few tries, but I made it. I'm not going to finish the 5th level. The first few sections are not fun enough to make it worth replaying them repeatedly to move forward in the game. So I would be in favor of a checkpoint system (try it in next platformer you make!).
I developed a couple of small demo games and one huge one (3-month project) with HTML5 and browser behavior is often lacking performance-wise, especially on Linux and mobile devices. I decided to limit myself to mouse controls only and slower games like turn based strategies or similar.
I have plans to make a faster 2D paced game this year and I'll go back to desktop and SDL for it. Especially since the SDL author joined Valve in 2012 and development pace has picked up again. Looking forward to run in on my Linux Desktop, Windows, Mac and a Steam Machine. I'm not sure I want to go any more cross-platform than that. Especially since mobile devices are polluted with low quality nickel-and-diming games.
I have input lag on Firefox, Linux. Well, maybe lag isn't the word, but it's definitely not responsive (meaning I did notice that being annoying before seeing comments about that).
The "coins are mandatory" message appears two screens after the first two coins. If you missed those, it takes about 5-10 seconds to go back. It's no biggie and certainly not a "dick move".
Spacebars have the same amount of throw as any key on your keyboard. Additionally, the force required to press the spacebar is less than other keys because the keycap for the spacebar is heavier.
On Safari 6.1.2 the second jump in the first level only works 50% of the time. The other 50% the jump only registers by the time the thingy has hit the ground.
Regardless of whether he made it in a week or not, the criticism by the OP was constructive. Just being nice and saying that "this is fantastic", wouldn't help the developer learn either.
*Input lag is something Carmack et al. keep hammering home for game developers.
Actually, input is fundamental to a game, because there's no way to make a game without input. It's one of the most important aspects of any game.
Making HTML 5 a serious gamedev competitor is one of the most important tasks facing the future gamedev industry, which means lessmilk is doing important work. It's important to call out the roadblocks so that the roadblocks get solved. It would be extremely valuable if someone were to do an analysis as to why the input is laggy so that future gamedevs can avoid that pitfall or that Mozilla/Chrome can fix their issue.
I don't see why having made the game in a week is relevant. Presumably this guy's goal isn't to never spend more than a week on a game. I interpret this criticism as "if you were to spend more time on this game, or if you ever make another similar game, think about these issues."
I think he made some really good and instructive points though, these are really relevant if you want to get better at game design. But I also agree that you have to look at this game as a demo and not expect it to be perfect in any way besides being a nice showcase of what you can achieve in just a week.
I'm impressed by what I've seen on lessmilk up to now by the way. Not in terms of coding (all of these games are almost trivial to implement), but all the more by the thoughtful game design that went in of them. Literally all of the 9 games so far have been fun to play, if only for a few minutes. I think it's much harder to come up with a new game concept every week, no matter how simple it is, and executing on it, than it is to actually do the coding to implement it. So thumbs up for that!
To me it depends on what the goal is. If the goal is to learn the programming side of things, then fixing up the controls / adding touch is a good goal because it would highlight figuring out how to get those things right even if it meant next week's game was this week's game + touch controls. If the goal is to explore gameplay ideas then input being a little sloppy is only as bad as its effect on playability.
I'm a hobby/hopefully someday profitable game developer who recently jumped on the "develop a short game in X days" bandwagon. My most recently made game was developed in 2 days [ https://play.google.com/store/apps/details?id=com.ektomarch.... ], and damn did it feel good to get something done that fast!
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.
I'd be lucky to even recuperate the $25 registration fee for Google Play. I put all my time into making games and zero time marketing them--if I flipped that around, maybe I could actually make a few dollars. :)
Putting out an ad-sponsored version might help, but I've been too busy with other projects to bother.
Unity is the best thing I've found for rapid game development. I also use Lua + Löve for a bunch of quick 2D games, but it doesn't run on iOS or Android like Unity does.
I've been following your progress with these games and there are several I really like, most of which is I think #5 with the cube jumping. I can't sing you enough praise on posting these as inspiration to others and sticking with the one game per week timeline. The motivation alone is inspiring.
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.
Here's an article with lots of interesting background info from the same author (lessmilk), "What I learned while doing my 'one game per week' challenge":
I really enjoy your games and (especially) the tutorial side. Great stuff! But I have been a bit put off by the frequent plugs for your newsletter. Of course, you couldn't have known that before commenting here, and so I hesitated a while before posting this. But I figure it may be a useful data point.
In any case, I hope you keep up the great work, I'll certainly be following!
Seriously. I thought I was fine until I was reading HN on my phone and thought to myself "hmmm... I wonder if the game works well on a mobile browser."
I think it's awesome. Haters hate. Love that it starts with a wtf challenge -- invests the user. Love that your exploring mechanics without all the news.
Why a week? I'm trying the "one game a month" challenge and I find it very difficult for one single reason: cut out things so it's possible to finish the game in a month!
Do you think it would be harder if you had more time per game?
i'm tempted to just get all those games, put in a "full screen" page and adding either touch events or simply using the trackball (which a few old ancient android phones still have)
I liked the games, actualy played longer then i intendet the #6 :=)
The Gameplay Mixing Board was used for the ingame music in the last one. Is this a free musik then, or did you just asked the autor to use it?
Platformers tend to be crappy on touch devices unless you're prepared to do a lot of work designing your game around both control systems, probably difficult in a week.
For this kind of experience building project I think it's fine to be a bit feature limited, however it would be great to try doing at least one touch only game to help build out other interaction options.
How experienced were you before you started? Have you coded before?
Any reason you're not open sourcing your code? Seems like it'd be a great idea considering you're still learning and could use some feedback from others.
Great job btw. Never heard of Phaser but now looking into it.
I'm impressed with the general quality:time-spent ratio.
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."
I think these are the best set of flappy bird clones that have come out yet (except perhaps the flappy bird orbital game).
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.
Well done! A few bits of constructive criticism, based on my own experiences with making platformers in GameMaker:
- 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".
It seems pretty stuttery on Safari running on my Mac, but was fun for a while - good job!
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?
As a mainly backend developer, I just signed up for the book, realised it didn't contain too much, but links to the tutorials. I had a quick read. and I would say it would be more accurate to call the title "One Javascript game per week". I got a bit excited thinking you could produce that sort of game using just HTML5.
Hope I don't sound overly critical, as its a cool game and I appreciate you posting it.
Pretty good game for a week. Most quick and/or beginner platformers I see have a lot of glitches with collision detection and response. You pretty much nailed 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).
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
Thanks a lot for posting this as well as one of your posts I saw a few weeks ago.
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.
This is great! It's incredibly awesome how much you can take away from Mario and still have a fun game. I love how the rectangle slants to show that you are moving. The game feels really responsive! (Macbook Air, Safari 7.0.2)
The progression in difficulty seems just right. This is exactly what casual gaming should be like.
yes i died catching my breath in the same place. i repeat what person above said about rectangles meriting perfect collisions.
still a nice diversion. i like the way on my system, several bitmap redraws occur per screen trace, giving the character a parallelogram shape. subjectively, it looks like he's in a hurry :)
After a little self-psychoanalysis I've realized that when I see "this is a hard level, you can't beat it", it makes me want to try even harder which is a neat idea to use in more games to get more people playing.
It's a great game.
Just my sort of thing really and I really like the music.
It only took a couple of minutes to beat though so it's a little short. Then again for a weeks work it's fine.
Keep up the good work.
Have you been writing anywhere about the things you've learnt so far? The challenges with the framework you've used or anything you started to do to speed up development?
I have been trying to write a small game. But after having seen this. Holy Cow! It's so minimally(don't know if that counts as an adjective) Awesome. Thanks for sharing.
I may have bagged this game for being way too simple a few weeks ago. But after Flappy Bird, the genre seems to live on. It's annoyingly great. Keep up the good work!
americans love to be positive but ill just be honest: the game play sucks. a great project for hitting out code and learning but pretty brutal for actually game play and enjoyment. but keep banging away at it, im sure a hit will come out eventually.
It started as a pure hobby with no revenue. But now that my project is getting a lot of attention, I might start making iOS/Android apps, or maybe write ebooks about how to make games.
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.