Language…
8 users online: cozyduck, Dark Mario Bros, Firstnamebutt, Golden Yoshi, Isikoro, krizeth, qantuum,  Ringo - Guests: 244 - Bots: 334
Users: 64,795 (2,376 active)
Latest user: mathew

Mad Scientist - ASM Contest [Final Results]

ASMResults

Originally posted by RPG Hacker
A programming contest shouldn't be about creativity. On top of that, the fact that it's this way also necessitates all these shaky explanations on what is and isn't allowed, which ultimately heavily comes down to interpretation.

inversely, wouldn't making a programming contest about the coding and not creativity just mean a bunch of entries that are effectively the same thing?

Like your chuck soccer ball proposal. I get it was just a quick example, but if ~30 equally skilled coders enter the contest and accidentally create the exact same soccer ball attack, then suddenly the judges either have a 30-way tie, or have to go through the code and pick and choose based on incredibly pedantic reasoning.

I'm not asm so I have no horse in this race, but as a spectator if each round was just everybody doing the exact same thing, that doesn't seem particularly interesting or motivating for entrants OR judges.

e: also im not too sure what part of the rules are confusing you. Again, it could just be an example of your concerns on future rounds to come, but I don't understand how you could possibly misconstrue "water or water enemy. if its not water or water enemy it doesn't count", unless you're deliberately trying to sidestep the rules (which based on your other point about not wanting to be creative, doesn't sound like an issue anyways).
ask me if i give a f*ck...
Small important news: I had clarified the last sentence in the second to last paragraph to remove the contradiction within the same sentence.

Originally posted by Ruberjig
Can we submit a "pack" or folder containing more than one thing related to the round?

The pack should be related to each other. But if you submit two unrelated things, you're essencially participating twice, thus disqualifying you for the round.
Even then, you shouldn't submit too much. As a rule of thumb, maximally three different sprites (not counting projectiles), one generator or UberASM code or one patch should be submitted (blocks are harder to count).
And please keep them atomised! If your entry is an ASM file which contains e.g. multiple unrelated patches, you're essencially submitting multiple entries. Same with sprites: If you have got a sprite with totally different behaviours depending on the extra property byte, it's three sprites in that contest.

This doesn't apply to auxillary resources, of course, as they aren't the main focus of the submission. Anoni's development version of DynamicZ doesn't count for the rule since that isn't what his submission is about beyond the submission's graphics.

Originally posted by RPG Hacker
I don't quite know about this one. I really don't. Since the task is formualted so openly, it actually feels like it needs a bit of creativity to come up with something, which isn't really what I was hoping for or what a programming contest should be about. Was hoping for something with more direction and more restrictions, requiring less creativity and more problem-solving. To me, that was one of the areas where the first Mad Scientist failed. A programming contest shouldn't be about creativity. On top of that, the fact that it's this way also necessitates all these shaky explanations on what is and isn't allowed, which ultimately heavily comes down to interpretation. If I were a participant, I wouldn't really want to think about whether a submission of mine fit that rather vague ruleset of what is considered a "water-based" entry. I also don't think leaving the choice of tool up to participants is a great idea. That just seems like it spells trouble. I mean, how is anyone even supposed to fairly judge submissions to a competition that could end up featuring, let's say, both a complex custom boss by one participant and a simple custom block by another one?

I disagree. This is a website which focuses on modding and in many instances, that is a subset of game development.
Of course, there still is a notable difference between creating commercial games and making a small mod. However, if a game was created by a small team of only three, four people, the coder is more likely to be also a designer. And SMW hacks take this even as the majority are created by a single person (albeit make use of the resource section) or if not, they're often teamed up with a coder who makes the bosses themselves.
It would have been a different story if we had a homebrew scene in which case general programming would have been more common.

There also is another reason: Judging. Problem solving, code golf and obfuscated code fit more with set judges who can take a look at the code but I picked public judging for Mad Scientist which and the judging is shifted towards gameplay and appearance than code.

Lastly: The advantage of open themes is to get a variety of submissions. Take a look at 24hoSMW: All of them feature a given theme and you have to create a level in a single day. Some of them are more open, which leaves room for interpretations, and some of them are less so. In fact, the last theme, four, was pretty open but it also had a low entry barrier. On the other hand,

Originally posted by RPG Hacker
Not to mention that this also raises the entry barrier for newcomers quite a bit. Let's say you were at an ASM experience level only capable of making somewhat simple custom blocks. If there was a competition focussed on just that, you might give it a chance, because why not, but with a contest this open where anything basically goes and someone could technically even code an entire epic custom boss with mode 7 and all those kinds of shenanigans, you'd probably feel way too demotivated to give it a try at your skill level.

I disagree: Which contest doesn't suffer from a "high entry barrier"? Just take a look at the latest level design contests and you'll often see names like idol, lazy, S.N.N., Sixcorby and worldpeace in the top ten (at least two of them, to be precise).
In my eyes, an open, non-technical theme is a low entry barrier since it doesn't require much technical knowledge to participate. The winning entry barrier is high, of course, but that's just a general issue with contests. If you know you can't make an appealing entry but still like to participate in a contest, nothing stops you from participating for fun.

And besides: Limitations isn't always an advantage for new users since one complain about OLDC is that the winners are the same as the aformentioned users.

Even then, I and lion discussed that coding a simple boss takes three days if you're focused and you have someone to make the graphics and a good boss in at least one week under normal circumstances with, once again, someone to draw the graphics. There is a reason why I forbid team ups for Mad Scientist.
I can speak for myself: My sprite coding tutorial is still missing graphics which is why I skipped the boss part.

To bring up 24hoSMW again: The winner of last 24hoSMW is Medic who showed off his coding skills but managed to finish up only four rooms (wait a minute...) so there is more potential to his gimmick. Second place is xfix with a Wario Ware-styled level with 19(?) rooms (not counting the starting level) and doesn't need to be any longer.

Originally posted by RPG Hacker
I really don't know about this one. I think I'll pass the first round, unless I can somehow miraculously come up with a solid idea that I feel confident would pass that vague "water-themed" requirement. I have already been disqualified from contests in the past for interpreting rules too liberately and I wouldn't want that to happen again, so the minimum I would want is for a round to have a clearly defined ruleset with little room for interpretation.

That sounds like you have PTSD about open themes. That's okay if you can't participate in this round. However, that makes your opinion biased. In fact, I disagree that the theme is vague. In fact, I would even argue that the rules avoids vaguely water related submissions such as disallowing ice and other forms of water.
Or how much is a fish enemy which is logically put underwater "vaguely" water related?

Originally posted by RPG Hacker
For the future, I would suggest going differently about this kind of contest. I would recommend applying a more restricted ruleset with more direction. Like, instead of just giving a vague theme, give a concrete task to complete. Something like "make a new Chuck sprite using soccer balls for attacks". That would be very concrete, less open to interpretation and yet would still leave some freedom on the details (such as how exactly the attack worked and how you would tweak it to feel more polished). It would also prevent that problem of having many different submissions completely different in nature. And to accomodate all the different skill levels, the different rounds of the contest could all focus on different aspects. For example, there could be a round dedicated to custom blocks, a round dedicated to custom sprites, a round dedicated to patches/UberASM etc.

See above: You're biased against open themes and I went with an open themes with the first round so it appeals more to. And besides: I can realistically only go with sprites and UberASM if I had to pick a theme with a certain resource type. Blocks? If you want to create awesome custom blocks, you can't go around sprites, UberASM and possibly patches. Patches? Could mean anything.

Also: A Soccer Chuck would be just a Puntin' Chuck but with a soccer ball, lol.

Originally posted by RPG Hacker
I don't quite remember, but I think this was pretty much exactly what I complained about for the first Mad Scientist: everything being too vague and open (I think I might have even given the exact same suggestions back then). "Make any bonus game" or "make any custom boss" just weren't really great tasks for a competition focussed primarily on programming rather than creativity, and "make anything water-based" is the exact same deal all over again, except even less focussed and thus even more difficult in my opinion. Unless you can quickly come up with an idea that you feel confident entering with, you're probably not even going to try. I hope I'll be wrong on this, but I personally don't see this kind of approach ending well...

A creativity blockage simple because you have got so many ideas to chose but you can pick only one... I can relate to that. But I also am positive that not everyone acts like you or me.

And this isn't always an issue why I couldn't participate in certain contests. Sometimes, I just can't find a good execution to a certain idea and sometimes, I just lack the time to finish the entry (as it happened last Mad Scientist).

Originally posted by Hobz
inversely, wouldn't making a programming contest about the coding and not creativity just mean a bunch of entries that are effectively the same thing?

There is code golf and obfuscated code which is about problem solving and creativity since the former requires you to write a small code and the latter a code which... just works even if it's a hell to understand. Those are incompatible to public judging, though.
I get your points, and if everyone else is also fine with this approch, then I don't really have any reason to complain. I just know that this kind of contest isn't really for me, but that's fine, it doesn't really have to be. I supose the chance that I was going to participate was relatively low, anyways (given the short time frames and the general lack of availability). I would still love to see a pure programming contest at some point, but I also get your point that every SMW hacker more or less has to be an "all-rounder". I guess the only option for people like me still remains collaborating with other people, so that I can focus on programming, but don't have the creative burden.

Originally posted by Hobz
inversely, wouldn't making a programming contest about the coding and not creativity just mean a bunch of entries that are effectively the same thing?


That's correct, and to me, that would be the entire point of a programming competition. It wouldn't be about what you make, it would be about how you make it.

To try giving a few equivalent examples: we do have contests where people compose their own custom music. Now imagine that in addition to that, we also had custom music contests where instead of people composing their own music, they would get a task like "try to port Gymnopedie No. 1 to SMW", where the best result would win. Sure, every entry would be the same song, but the results would still be vastly different. Art contests in general are also often good examples for this. Art contests are often in ths form of "draw this character, the five best entries win x". Basically, that kind of contest is what I'd be interested in.

I guess you could say that one kind of competition is a measurement of creativity, whereas the other kind of competition is a measurement of skill. Which I admit kinda contradicts my point about the entry barrier thing. I also acknowledge MFGs point that this kind of competition wouldn't work with a public voting system, as it would require average users to be familiar with coding.

I guess above all, I was just initially disappointed that it's another kind of contest that isn't really for me, but then as I said, not everything has be for me and that's fine.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Does everyone see this image of a water molecule right here?



I am going to make this into a custom boss with pseudo 3D effects where the balls overlap each other and such. Kind of like how Vector man looks on the Sega Genesis.
entries are supposed to be anonymous you eediot
idk being ballsy like that is pretty based

allow shy guy emojis in post footers you cowards!
Originally posted by anonimzwx
If i do 2 or more versions of the same sprite, it is considered as 2 or more entries even if they use same/similar graphics?

In that case, you have got two variations, it's fine.
I probably should've asked before I started working on this, but is self-plagiarization something I have to worry about here? I have existing (publicly uploaded) code I wrote a bit ago that I'm using as a reference while working on this. The actual lines of code for my submission are like 90%+ original for this contest, but the... idea? framework? idk whatever you'd call it, for the code is pretty blatantly identical to the old stuff I'm referencing. Just making sure I don't get dinged on some technicality.
I mentioend that at least 2/3 of the code needs to be original (and 90% is more than 66%) so using an existing sprite, be yours or someone else's, as a very basic framework is fine as long as you provide enough differences.
Animated GIFs are since videos are animated pictures, just their implementation differ. As such, they indeed can be used.
I got a notification from staff that big uploads to the File Bin are logged thus spoilering the uploader's name and potentially prevents them to participate from judging. Relatedly, your file bin is public so anyone can in theory just look up a participant's bin and notice who made what submission.
It's preferable to use alternative hosting methods such as Dropbox or Google Drive until we find an alternative solution.
And the time is over, no more submissions can be accepted! Voting will start in about an hour!

Round 1 - Voting

Alright, all the entries have been compiled into a single folder. Here are all the entires entries for round 1:

You can grab all the entries here.

To remind you on how to vote: You post the order of the entries where the highest ranked entry gets the most points. Don't focus on their names, presentations, audo or graphics but rather on the entries themselves i.e. how did they impress you, how fun are the entries to play and/or what are the entries' quality. Participants cannot vote.
You have around four days to submit a judgement. That means, round 1 ends at and round 2 starts at October 21th, at 18:00 UTC!

Edit: Added video links to the entries.

Edit²: Added Size which I have unfortunatelly overlooked.
Vertical
This is an incredibly creative entry, and one that's simple yet unique! It's neat how comparatively smooth the animations are and how natural everything feels.

Sphere
I really love this entry for its versatility and how much life it gives to vanilla SMW sprites and even to Mario's movement. It felt like the entry just kept on giving as I progressed through the test level.

Eel
This entry is adorable, and I especially love the wall unagis. It's cool to see them ported to SMW, and so neatly and smoothly too!

Rising
This is a very straightforward entry, and definitely impressive in the way it brings so much life in the usually-limited layer 3.

Battle
While definitely cool and well-made from a coding perspective, I feel that this entry falls flat because of how clunky it is to play. I think it has the same issue that a lot of Brutal Mario bosses have, in which the recreation is very neat, but the gameplay doesn't translate well to Mario.

Size
This is a very neat idea, and graphically it's really pretty, but unfortunately, the biggest detriment here is how heavy Mario feels inside the bubble. Controlling him feels quite difficult, even for simple setups. With some tweaking for the controls, this has the potential to be quite fun.

Minigame
While I like the idea and gameplay behind it, unfortunately, the fact that there's no endgame or reward for how many fish you catch makes it a bit incomplete. Still a great concept though.
EDIT: Forgot to mention, grab the grab blocks in the middle of the level for a fun surprise!

Boost
I recognize what this entry is trying to do, but unfortunately, I think the controls aren't very user-friendly. I think some touch-ups in that regard would be a significant improvement.

1) Sphere - I love sprites that can interact with other sprites really well. Extra credit for player interaction.
2) Vertical - This could make for interesting puzzles and levels and it looks impressive.
3) Rising - Controllable tides are pretty cool; these blocks are reminiscent of those weird diamonds from wet-dry world in SM64.
4) Size - This is really cool in theory, but it's rather difficult to jump out of the bubble. Mario also sinks like a rock if you fall into it, which is unexpected.
5) Boost - Pretty interesting way to gain height out of water, though it's weird that you cannot turn around underwater.
6) Battle - Decent boss, though pretty simple
7) Eel - Cool looking sprites, but they don't change much in water vs out of water. I like that they are accurate to NSMB though.
8) Minigame - I feel like you can use this net out of water to collect sprites and not much would change. I got a crash midway through the level for some reason.
- Sphere: While this one is on the simple side, I see tons of potential of it being used in puzzle levels, in fast paced sequences and so on. Just because of how many uses it can have, I'm ranking this one higher. Sprite interaction is very neat and has some insane possibilities of combinations.

- Size : While not as flexible as the one above, this one leads to tons of creative setups. Really clever idea and I already imagine some insane setups being done with it. With that said, I would love if there was an item that decreases the water shield, so it would reduce and player would have to avoid it. Anyway, loved that one.

- Vertical: This one is great. The water follow physics laws and I see it working great with puzzle levels where you need to get stuff done in the right order. Tons of potential.

- Battle: This one while not as flexible as the other, I think it's a very nice entry. Fun to fight, intuitive and the second phase is even harder. Definitely not a first boss. But can work great as a late game boss.

- Rising: Very nice mechanic. Has tons of potential to make a good level. I found the water rise a bit slow, though, but overall, it's a neat mechanic.

- Minigame: Has a neat concept of fishing with a fishing net.. I think the hitbox is kinda odd, but anyway, it's solid enough.

- Eel: This one is nice. Nothing too outstanding, but hey, it's a solid entry. Overall, very nice to have more NSMB enemies in SMW.

- Boost: The ideia is neat, but the controls are kinda confusing. Very nice, but I didn't enjoy as much as the others.


1. Sphere - Even just from this short demo, there's so many potential ideas you can do with these bubbles. One little thing I noticed is the bubbles can take the item you're holding, which is a really nice touch. With all the different speeds, patterns, and items you can use with the bubbles (not to mention that it probably works well above-ground too), I would love to see this get used in some actual hacks.

2. Minigame - This was a really neat entry. While the demonstration itself is pretty basic, I can imagine a lot of neat ways you could use a fishing minigame; maybe incorporating it with a Yoshi Coin, for example. My only gripe is having to use Up instead of the Y button; I guess it's so you can still shoot fireballs, but I'd rather it just replace them as long as you're holding the net. Otherwise, it's a fun idea.

3. Battle - Not too shabby of a boss fight. Simple patterns, but they get the job done, and the second half is a nice twist. It maybe felt like the health bars were too long or the fireballs were too weak, but it's not too much of an issue. I think Mega Man bosses might be a bit cliche, but it's still decently made.

4. Vertical - I've got mixed feelings on this entry. It's cool to see something so physics-based in a Mario level, but I'm having a hard time picturing it in action in a fully developed level. Without going into Lunar Magic and messing with the level myself, I can only make assumptions, but it feels like it'd be easy to break if the player does something unintended, or if the designer does something screwy. Still, that's all hypothetical; going off just the demo, it's a really fun idea, and creates some interesting scenarios.

5. Rising - It's a simple idea, but there's a lot of potential in the gimmick. I can imagine something like a sewer level utilizing it very well. I wish the demonstration had more to it, though, as there's not really much to go off aside the basic gist of the entry. Like I said, though, it's ripe for experimentation.

6. Boost - It's a little bit awkward to handle, I feel. Obviously the turning is weird, though I guess that's part of the challenge, but it seems too quick going down and up. I pictured it more like a charge function, like you have to force Mario down underwater before he shoots back up. It's an interesting idea, at least, but could have had a better execution.

7. Size - It's a neat idea, but really frustrating to control Mario inside the bubble. You already mentioned how hard it is to jump out, but it's also really easy for Mario to fall through the bubble hen jumping into it. It's also a little bit glitchy; sometimes the bottom half doesn't shrink. With some improvements, it'd be a really neat level gimmick.

8. Eel - This was an odd demonstration. The free-swimming eel just sort of floats up and left, and isn't able to turn around; nothing terribly wrong, but in a normal level it feels like it wouldn't be much of the threat. It also looks really awkward in "ground mode". On the other hand, the wall eels take a lot of time to attack Mario a second time, so they also seem really easy to dodge. Unfortunately, based on this limited demo, I can't see them being too useful as an obstacle for the player with all these setbacks.
1. Sphere - I think there's huge potential in Sphere because of the way it interacts with Mario, terrain, sprites, and its movement settings. Definitely some great level-making opportunities with it.
2. Size - This is so cool, it reminds me greatly of the Fuel Platforms in Donkey Kong Country 1. The different sizes of water pickups are a good idea too because you can create moments of tension where you need every drop, and release, where you get the big bottle and fill the whole bubble for short relief.
3. Vertical - Something I could definitely see being used in puzzle levels, or as a cool way to dynamically fill a room in levels that represent changing water height through sublevel changes. I'd love to see a way to drain or shut off water sources too, for further puzzle or exploration opportunities.
4. Battle - Seems like a pretty competent little boss fight, complete with a two-phase structure and variation mid-fight to make it interesting.
5. Boost - I think this could use a sound effect or two but otherwise it seems like a neat piece of underwater movement tech. I especially like the high jump you can make coming out of the water using it.
6. Eel - Very impressive, especially how it has both underwater and out-of-water states, and even the wall-based variant. It does seem a bit one-note though, and while its graphics are very impressive they're also so complex and smooth that it feels like it would be hard to find much use for this outside of very specific kinds of hacks.
7. Minigame - Cute game, but I'm not really seeing the purpose of it. Like, can it be tied to a reward of some kind? I also think pressing Up for the net is a poor decision, and would be better suited to X, L, or R.
8. Rising - Simple, does its job, but is probably the least ambitious. Not bad or anything because it has a clear purpose. It's just less impressive than the rest.

ASMResults