LoginLogin

Spring 2019 Mini Programming Contest

Root / Site Discussion / [.]

YolkaiCreated:
Woah, many thanks guys!

I honestly knew mine would fail from the start. I guess this is what happens when you shitpost.

I will get the badges for QSP soon. Can't do them now though, sorry

OH SHI- WHEN DID ALL THAT TIME PASS BY

Tsk tsk still procrastinating I see

OSP submission has closed! As before, the key (hosted by 12Me21) is in the poll title. Try the entries (information at http://smilebasicsource.com/osp/) and vote for the 3 that you think are the best OSPs. [poll=p562][/poll]

My high score for 12_CAVE-2 is 5395. Very fun game! I don't understand what AU-TREES does... you can tap the screen once to have a green pixel show up, but then nothing really happens. Am I doing something wrong? COLLECC is my game. The game always uses the same seed, so all items should be in the same zones for everyone. Feel free to ask for advice as for where some items are! FLIPBOOK_OSP was fun to mess around with, and it looks super clean too! MAL-ESQUE doesn't have much content to it, but it's always nice to see people trying their best. My high low score for NA-SIMPLE_GOLF is -8. Looks great and was a very enjoyable experience. My high score for SIMONE-PROKUKU is 16. A classic. Well done! T_HOLE seems like an interesting idea, but unfortunately I quickly found out you can just hold up and right at the same time so your car doesn't move while you still gain score. Furthermore, it's always just a matter of time until a hole spawns right under your car. I would suggest for example to make the car constantly moving (like in Snake) so you can't just stay there doing nothing, or to make it so you can see where a hole is about to appear, so you can move away from it in advance. I think this game has real potential. I must say I had a lot of fun playing WALKTRAP. I'm amazed how the author was able to fit so many puzzles in a OSP! Y_APHS_DEMO... lol it's touhou 1. The physics are... strange. The ball seems to get stuck in your knives, and your player is so slow it's sometimes impossible to get to the ball in time, even when diving. On the other hand, I was impressed by the tiles making the shape of random kanji. Good job!

If someone gets to 25 on Simone I'll personally give them a cookie

See if you can find the 3 secrets in my game (one of them isn't really a secret since I mentioned it in the description. If you hit your head on a ceiling, you can jump again. The easiest way to do this is to mash the A button. This allows you to jump to places that you wouldn't be able to otherwise.) And my highscore is 5759

oof my entry must not work om o3ds lol

If someone gets to 25 on Simone I'll personally give them a cookie
ok accepted

I just noticed that the way I made my program’s box-checking stuff causes you to automatically lose the game if you tap anywhere that isn’t a box. Sooo make sure you have good aim when playing I guess.

I just noticed that the way I made my program’s box-checking stuff causes you to automatically lose the game if you tap anywhere that isn’t a box. Sooo make sure you have good aim when playing I guess.
That's called a feature

Yes indeed it's not a bug it's a feature.


It turns out WALKTRAP runs poorly on o3DS. I had the ability to test this but didn't; we regret the error. An updated version will be released after the contest.

I expect my entry to run poorly on the o3ds. I didn't have enough space to implement frame flipping to stomp out any flickering.

I, also, must admit that my program may run poorly on a device such as the old 3DS... the touch screen checking and color coordination and noise making is very overwhelming for such a weak system. Proceed with caution, please.

The o3DS is just *barely* fast enough to scroll an entire screen of graphics using GCOPY. I originally drew new tiles like 100 pixels below the bottom of the screen, but scrolling the extra data was too much and the entire game slowed down, so I had to put them just barely offscreen. As a result, it became very easy to fall off the bottom of the screen (since there wasn't a bunch of extra terrain down there anymore) so I had to change the collision detection function. Even after that, though, I noticed that using SPOFS after the GCOPY would cause the sprite position to be updated 1 frame too late (I guess if you use SPOFS too close to the end of a frame, the new position isn't used right away) So I had to put the SPOFS before GCOPY Anyway, a poorly written explanation: https://raw.githubusercontent.com/12Me21/12Me21.github.io/master/sbcode/12_CAVE-2_EXP.PRG

my program is probably bad too ... definitely bad on o3ds