@chance's entry
I do believe I've seen something like that earlier on, probably as one of these little mobile games. Fun to play for a bit, though personally I'd prefer if the game reacted to keyboard checking rather than keyboard presses (alternately, be rigged in a way that allows declaring a jump a few frames before landing; one of these tiny tweaks that make the game appear smoother without the player noticing). Also, I think Space would work better as a restart button at the end, considering R is not used anywhere else. Bonus points for sounds and the silly bouncing text on menus.
As for the code, it generally looks fine, though it seems rather inflexible, what with each level being limited to 3 obstacles and the same obstacle sprite (to alleviate the first issue, you could have used a ds_list of obstacles instead). Also, the level declarations seem quite repetitive; I feel like some parts could have been shortened. Finally, you might want to use data structures accessors (instead of ds_map_add/replace). ^^
@Coded Games' entry
Well, indeed it is pretty unfinished; I can tell that even without looking at the comment at the beginning. Still, it's an interesting idea to use procedurally generated planets, with different hues, conditions and terrain (the terrain pretty often seems suspisciously sinusoidal, though; is it actually a sound wave surfing game all along?).
When it comes to the code, one thing that struck me as odd is usage of 2x30 grid for storing variables, mostly the fact of using two columns. ^^'
Also, personally, I would still name the 0-indexed grid somehow, to make its purpose clearer (and, as an added bonus, to allow using grid accessors).
By the way, I noticed a line like
file_delete("Game"). Were you perhaps initially trying a file-IO data storage method, before settling for 0-indexed structure?
Shooting Star by @Galladhan
Hmmm, so I am supposed to fly forward until I run out of lives, and get the highest level possible? Sounds like a game that could use hi-score tracking...
Aside from that, the game is a bit confusing; I had hard time understanding when I lost lives, and when I could just slide on the floor without worry, and whether these shiny squares harmed me or not. Also, there should be a mechanism that prevents a player from running into terrain the very moment the level begins.
On a side note, I see you use file-based variables keeping method? The code seems kinda fine at a first glance, if maybe a bit undercommented (I don't quite see what happens in the room_init phase, for example, with all these rows of unknown purpose and such). I didn't quite feel like playing around with it more, though.
Forest Fox by @JimmyBG
Nice little game, with a good use of 3D, though the fox running animation isn't really top-notch. Also, I didn't know I could use Space to jump until actually looking in the code (ASDA! Is that what the fox says?), and I don't quite like how the tree in the middle covers the rest of the middle track, which might very well be another obstacle (it makes switching from a side to the middle lane pretty troubling). Finally, as a hi-score based game, it really should persist the score somehow (even the basic text file...).
The codebase is rather large, but about 2/3 of it is initialisation of the models (computer-generated, I presume? Typing all these vertices yourself sounds looks about as exciting as making an Excel document from a table spanning across tens of paper pages, without any smart scanner at your disposal). Aside from that, the code seems pretty straightforward, and if I looked into 3D I probably wouldn't have trouble figuring the game out (especially with comments posted every now and then).
@Matthew Brown's entry
Yay Yay Yay Yay
Entertaining to play for a while, but pigeonhole principle eventually had to kick in and some events were repeating (sometimes resulting in having the same event in a row). They seem to be picked entirely randomly, too, without any rigging to make the distribution more even (e.g. shuffling instead of picking random event every time). Somehow, I found money had the highest tendency to be the lacking resource. Still, the events that were there were pretty good, and somehow, trying to pick the "optimal" answers, I lived through the 52 weeks.
When it comes to the code, it doesn't seem particularly sophisticated, and it uses the OSG classic 0-indexed structure game state. One thing that stood out to me, is how the game first declares all the questions, then all the answers, then all the consequences, in that order. I would rather put all the related data around the same place, i.e. question 1, answer 1 with consequences, answer 2 with consequences, answer 3 with consequences, answer 4 with consequences, then question 2 etc. As it is now, it makes things unnecessarily difficult for the developer. Also, all that data seems to be declared every step, for some reason, rather than during the initialisation.
(full disclosure - I would just keep all the questions and related data in a JSON, because JSONs are really useful for that, and much better than hardcoding that sort of data in GM)
Mega! Super Smash Track Buggy Racer by @Mike
Well, it was pretty fun to play once I got it figured out, though the beginning is quite rocky. Part of that might be the fact that the car doesn't change its appearance when steering left or right, so it is hard to tell whether you're on a good way to turn or not. I find it interesting that the game includes a bonus of sorts for surviving two laps in a row, as the first lap always comes with a few additional seconds before crossing the starting line.
Also, there are some tiny visual glitches (e.g. the green line at the bottom appearing occasionally, as if the road isn't entirely drawn, and the tunnel with the outside shown was a bit weird), but nothing too major. A tiny suggestion about scanline effect - having alternating, low-alpha black-white lines ensures that scanlines affect dark and bright objects alike. Overall, somehow, I ended up playing that for FAR too long.
(oh, and one more thing - why hi-scores aren't stored between runs? It isn't much to add, and is a significant improvement; one of the essential thing about hi-scores is that they stay, after all)
The code seems generally well-structured, and the usage of recursion to make the one script multi-functional helps it even further. Going by the variable names and comments here and there, I can get the general idea of *what* is supposed to happen in a piece of code, even if I'd need to look into it more to tell *how* it does it. One thing that I found confusing is how the naming conventions seem all over the place, when it comes to usage of snake_case, PascalCase, nocase, ALL_CAPS, _underscorePrefixed etc. (with different conventions used for seemingly similar entities). Maybe there's some well thought-out pattern behind these, but I can't quite spot it. ^^'
On a side note, somehow, I never knew of draw_sprite_general before. The things you learn...
@Nallebeorn's entry
Well, there isn't really much gameplay here. ^^' I appreciate the platforming mechanics, though they could be tweaked in a few places (in particular, it would be good if the character didn't wall-slide nor wall-jump when a left/right key isn't held). Also, the animation seems a bit buggy (too bad, because it's pretty good otherwise) and there's that weird glitch when you randomly fall through the bottom when walking right on the lower-left chamber floor; I have no idea what can be the cause...
The code is mostly clear about its intent (even though the implementation is kinda buggy...). The use of underscore for the main map kinda reminds me of Lodash (a JavaScript library).
Asteroids by @Nocturne
Gah, that's game is really well-polished, and quite impressive for only 16 hours time and such, and I'd really like to like it, but it has a major flaw - it's just kinda boring. I think the movement is largely to blame here - the original had the ship inert, drifting for a while when left alone, with the ship direction affecting the acceleration rather than the movement. Here, the ship stops quite quickly (where does the friction in space come from, anyway; solar winds? ^^'), and changing its direction means also changing the movement direction, completely unlike the original. I believe that factor makes the game much less entertaining than it could be, taking away the challenge and fun of the inert movement.
Well, at least this game, as the only one of hi-score based here, actually persists the score. ^^'
When it comes to the code, it seems presented and commented well enough (you seem to really like short variable names). At least, it's understandable enough for me to implement the inert movement instead of the one submitted.
(on the other hand, I can't quite find where I can tone down the afterimage a bit...)
@PsychoDelph's entry
Well, more of a prototype than an entry. The parallax effect, the enemies closing in and the changing background colour are nice, but a bit too little compared to other entries. Plus, I've found that at specific angles the backgrounds are cut off at the bottom (i.e. there's regular background colour shown below them). Also, the lag when clicking the enemy, however intentional, is pretty annoying.
It's rather interesting how you seem to use tiles all the time to display the gameplay elements, instead of drawing background or sprites; perhaps it's so that tiles fulfill the role of objects or something? Pretty unusual method, nonetheless.
@shadowspear1's entry
Uhhh, dammit, this game uses
buffer_set_surface which doesn't work on my computer, which means basically nothing displays except for the game map, so I can't really evaluate anything here, sorry...
Also, it seems some grid size checks are in order, as when I moved the mouse around and clicked in various places, I kept getting grid out of range debug messages. ^^'
NOT TETRIS by @Surgeon_
Pretty interesting concept, with matching the blocks in groups of threes or more then removing the groups manually. However, I have found some strategy to be pretty effective - wrapping the core so that all 8 neighbouring blocks belong to a group of 3, then gathering blocks to rack up potential score (especially glowing ones), then triggering the removal as soon as some bombing orb comes too close, removing literally every block except the core. That strategy, aside from initial wrapping, kinda misses the main challenge of the game (matching the same block). Also, after getting a score of over 5000 and triggering another removal, I got an error (I didn't know I could ignore) and stopped my run. :< And, once again, this game doesn't persist the hi-score! >.<
(I kinda liked the font colours, by the way
)
The code seems to use a recursion scheme for different functions; clever, though you weren't the only one to think of that.
Also, the code was clear enough for me to find out how the score is calculated exactly and use it to my utter advantage, but I guess you know that already. *whistling*
Flappy Souls by @Threef
Interesting idea for a game autobalancing; too bad you missed "EVERYBODY IS DEAD" or "Dying gives you twisted benefits" Jam. ^^' The execution could be refined a bit, though, in particular there are some parts literally impossible to get through, and the high jump power makes it quite hard to navigate properly (requires taller gaps to survive). Also, there seems to be no goal to reach or anything, and with more and more area cleared, you repeat the same level part over and over again, ad nauseam. The startup gets more laggy, too, which might have something to do with increasingly massive JSON file storing the game data. Oh, and nice that the game includes the sound, but it is pretty annoying, especially the flapping sound. ^^'
The code seems clear enough, and gives no trouble changing the key variables (like jump power or sound toggling).
Pool by @YellowAfterlife
That's some really neat entry, what with that pool aesthetics and pretty fresh idea. Some things could use tweaking, like the time of calm between rounds could be reduced (it's particularly annoying around the beginning) and the epileptic eyebrows. I'm not exactly a fan of corner pockets, either, though I admit it *does* make for a good balancing mechanic. Overall, I managed to pocket 75 balls in one go; that's like winning a game of pool 5 times, isn't it?
I don't quite like the code, though. As I understand, it has been Haxe-generated, which apparently has the drawback of having rather sparse comments; thus, I can't tell at first glance *what* a given piece of code is supposed to do, whether through comments, variable names or other indicators. Also, that "if (true /*comment*/)" construct looks a bit weird.
'
Too bad, because I kinda felt like playing around and discern between POCKETED and K.O. messages, as well as add FOUL losing condition when you pocket an 8-ball while coloured balls are still present (and maybe make it so that each round has at least/exactly one 8-ball in the pool). That game basically asks for it.