Why just not ask?
It's kinda rude talking "they" about people on the forum
TL;DR: In our MK port there is not a bit of code from any "Arcade source" and no insight how it was written. The code except Handy Music driver is ~100% ours. I even wrote by myself a custom loader, initialization routines, Suzy handling etc. About making ports in the competitions I'll write at the end, but now I have an urge to write some about the technicalities as it's important to understand the point.
So basically the "fighting engine" is only the tip of the iceberg. I don't mean it's trivial, but if you have enough idea/knowledge about game mechanics it can be written in... let's say... a week. Some more if you are doing it in assembly as we did. Actually @solo/ng is a hardcore lover of the genre and he knows all the moves by heart and he was tweaking it until the deadline, so we haven't benefit much from that edition of Silly Venture
Under that is a Sprite Drawing Engine intermixed with Resource Management Engine. That's where the magic is happening. I was writing all the tools and 6502 code about half a year - from June of 2019 when I've learned about Lynx 30th anniversary competition and the goal happened to be the Lynx Quest. For that game I did a tool that manages assets and divides the code to separately loaded "stages" and it was designed to make it quickly and easily. It has also pretty efficient routines to draw sprites - virtually any stone and clump of grass is a separate sprite there and you all can judge whether it's sluggish (That's the only reason I was whining in the Odynexus thread as I know that anything that is on the screen it that gorgeously looking game can be drawn faster).
When we've decided to make an entry to Silly Venture game compo I was initially planning to do some survival shooter (akin Phobia II) but few weeks before the party @solo/ng presented a proof of concept that MK can really be done and look great on Lynx. Initial concept has been hence dropped and we started to evaluate what is needed to do full fledged Mortal Kombat clone stripped down to Lynx' capabilities. Soon it turned out it would not be a Mortal Kombat that "complies with our standards" if it would sacrifice fluidity of (many many frames of original) animation and if it would not have samples played during fight. So We've faced the same problem that @Nop90 is facing now in his Starblade fighter game. The difference is that the "memory optimization" was off the table because sprites of fighters occupies more that 64 kB. Not to mention many kilobytes of samples... So rather than saying that it's impossible, I've made it possible pushing my resource management way further that's reasonable. At the end our gameplay has about 30 fps what includes drawing two layers of background with parallax, two players with shadows, some UI and few palette changes amids the screen. But the core concept is that we are loading required resources on the fly. The are few pieces of puzzle here:
Our rendering takes less than a 1/60 of a second (a frame) so in every 2-frame rendering cycle we have 1 frame for rendering and 1 frame that we are using to load the resources.
MK animations have 10 fps, we are rendering 30 fps so any change in sprite occurs every 3rd refresh.
Longest animation have 8 frames. We can load 2 frames in one loading cycle so we can load 6 frames before first frame is needed
The samples are needed not sooner as at third frame of animation (kick, punch etc) so we have theoretically plenty of time to load all sprites before we switch to streaming sample data on-line from cartridge (in practice there is no much time left as there are two players that need to have animations loaded).
Keep in mind that all these resources need to be managed, kept in cartridge, addressed, and have to have some place to be loaded to RAM and accessed without glitches. To speed things up I even devised a way of ordering cartridge blocks so that switching to next block would need shifting only one bit to IODAT.
So without false modesty I think that the engine behind Mortal Kombat is really a piece of cutting edge retro-technology that I don't think has been done before on Lynx. And to be fair I wrote it only because we were doing Mortal Kombat that already has resources that are demanding to fit in. If it would be original game I would probably given up and "ordered" simpler assets that would fit in the memory.
After saying all this I think that the only thing that is unfair here is to diminish the accomplishment of doing something theoretically impossible only because the idea and assets are not original. Of course there should be rules that needs to be followed. We did original game to 30th anniversary competition because rules said so. We wouldn't submit a port of AAA game on the competition held in this community. On the other hand, @agradeneu, you probably don't fully understand the concept of competitions on demoparties. The idea there is not to present a demo-version of a game that you wish to sell someday later, but to push the limits and present something as impressive as you can. So, please, let's don't mix these concepts.
My friend told me that I had very sour face after the announcement of the results
But that's the way democracy works. The Silas Adventure had 3D dungeon and we had only two moving sprites. Sadly the majority of voters didn't know what are the capabilities of Lynx and apparently voted using their gut feeling.
PS. As a side note about Lynx Quest - I've actually published it's source code about 8 months ago on ChibiAcumas assembly forum and was waiting all that time whether it will be discovered. It wasn't, so it kinda proofs my hunch about very little assembly interest in Lynx community . I stop waiting then and you can find it here. BTW I won the Tiny PacMan with it.
PS2. We will push MK further. Multiplayer game waits when I'll stabilize my com-lynx code (as I strongly don't like the way it was done in the redeye). We'll add some more animations too.