forums.marpirc.net

Ok, here's the deal.
<p>

The fundamental problem with MAME inp files are rerecordings,
and play on a slow machine.

<p>

If MAME was changed with a good encryption scheme which also
included frame rate information, cheating would be almost
impossible. It really shouldn't be too difficult to add this to
TG MAME.

<p>

It is all for naught if none of the players use this new version.

<p>

So I am proposing setting up an anonymous ftp site with the tournament
version. Anyone who wants to can download this new version for
personal/tournament use only. This is allowed under the MAME license
aggreement.

<p>

To put it bluntly, if you are going to have a tournament, why not
making cheating as DIFFICULT AS POSSIBLE?

<p>

The new version will have the following features:

<p>

1) No rerecording ability
2) No pause
3) New and tougher encryption
4) Time stamp for the frame rate
5) No distribution of source

<p>

Anyone who wants to can download the new version anonymously.
This is probably the last time I'm going to open this particular
can of worms. It's crystal clear to me that some players are using
some sort of slowdown scheme for T2. This is a viable way to correct
that problem. If there is no interest in this from the players
then I'm going to stop posting about this on MARP.

<p>

Please let me know what you all think.

<p>

Mark

--
cubeman@iname.com

I'll second Mark's motion. Maybe instead of pausing - we could count
the number of pauses and how long each pause lasted - but I'll leave
that up to Mark to decide. Regardless - I will try to insert
whatever version it is into the tournament for January.

--
goldengameboy@yahoo.com

While I love to cover against illegial recordings as much as the next
person, here is some notes.
The slowdown is done by a rather little program known as mo-slo. It's
intentions were honest enough (to allow play of old MS-DOS games that
with the new machines ran way too fast to play), but has become the
cheaters weapon of choice. Mark, you program would suffer the same
fate in that regard.
Gameboy, if we require it for the tournament, then we are back to the
problem Nicola mentioned. Anything for public use, (aka tourney)
would, according to MAMEDev, require distribution of source code. (I
would simply make it next to impossible to find it, though!)

--
cparsley1@hotmail.com

This is the best we can do (at the moment) to prevent slowdowns, i'm
all for it. But, mark, I strongly suggest to advertise for some
hackers to help us. Make sure you give it to some smart but honest
hackers and if they can't hack a cheated inp out of it then force
everyone use it for the next (or current) tourney, however you will
also need to learn how to compile win32 tgmame to allow the "butt
kicking" users to play.

--
churritz@cts.com

As a member of the 'Howling Fraternity' whose motto is 'standardise' -
I'm all for it. (1)-(4) should be no problem. As Chris says there may
be an issue with (5).

<p>

In reference to the source distribution. I've mentioned this before
but noone made any comment. Would it be acceptable to MAMEDEV licence
to 'delay' distribution of the source until after the tournament. In
this way we aren't denying anyone the source but are only making them
wait a couple of months for it. 'We are commenting the code to make it
fit for distribution' is always a good excuse .

<p>

I had another read of the MAME licence agreement at
http://mame.retrogames.com/. The below extraction is the relevant
part:

<p>

Source Code Distribution

<p>

If you distribute the binary, you should also distribute the source
code. If you can't do that, you must provide a pointer to a place
where the source can be obtained.

<p>

How about providing a pointer to a currently nonexistent ftp site that
we are setting up. The setup for this ftp site will be 3 months just
after the tournament ceases (surprise).

<p>

Another way around it may be to issue the source code 'on request to a
particular nonrobotic email address', then only check that email
address and respond once every 3 months. I even have the cover email
in mind

<p>

"Apologies for the late response to your request for source. I've been
particularly busy lately. Here's the relevant (out of date) source
you were after 3 months ago. Enjoy!"

<p>

Now the only problem is that some legitimate competitors with
particularly slow machines are going to be excluded from the
competitions (can't run games fast enough). This is regrettable but
there's nothing else we can do. The words 'upgrade' seem to leap to
mind for those people.

<p>

Tim

--
tjmorrow@bigpond.com

Mark, I think you hit all of the major shortcomings of MAME. However,
I see #4 as two separate problems. The start/end time stamp for a
recording may be correct, but if someone is playing with a high
frame skip rate, that's a different animal. Looking at a time stamp
alone wouldn't catch that. Also, there may be utilities out there
that can pause a MAME thread, where someone doesn't have to use the
PAUSE key. The time stamp code would have to look at the bios clock or
could count the CPU cycles since the initial INP file creation time.

--
laffaye@ibm.net

As a co-founder of the 'Howling Fraternity', I fully agree with
Mark.<br> Anything that could prevent, or at least make very
difficult to cheat, is most welcome.<br> Issues #1,#3 and #4 are ok.
#2 is ok too, but I have to agree with someone who said the pause key
, at home with a wife, kids, and so one, sometimes is necessary. So,
even I always asked to disallow pausing, I think that pausing (but
blanking the screen, so not to give the advantage to 'stop-and-study-
the-situation') could be allowed....it's up to you, Mark.<br> As for
#5, I already proposed to consider TG Mame as a private release, only
distributed in the Marp community, so not to be obliged to release
sources.<br><br>Cicca

--
cicca@writeme.com

Looking at the timestamp code would catch people playing at a high
frame rate, since the differences between timestamps would be smaller
than expected. I think most games, if played at a higher frame rate
than stated, are going to be more difficult to play in such a manner.
The only exceptions being if you could slow down the hard sections and
then speed up the easy/wait sections, this would be difficult to
coordinate however - to ensure you get a timestamp difference at or
under expectations. Perhaps the F10 key should also be disabled to
prevent people from modifying the duration of play? That would suck
since you can't speed up confirmation playbacks... Although i think
the playback functionality should be taken out of the
distributed TGMAME distribution all together and only mark or an
authority would be able to confirm recordings.

--
churritz@cts.com

I held another tournament at http://get.to/hcc and I suffer the same
problems as you. I think the good way is to use on-line gaming.
It means that the game is played on-line and data are sent to the
server at runtime. The server then knows if the speed is correct etc.
This also requires Mame without sources to avoid procedures like
making .inp file at lower speed, and then playing it back at normal
speed and recording it to another file, etc.
BIOS time stamps are obvious, because anything else is very easy to
hack. Also, tournament Mame can be only plugin for Mame32. Then you
can distribute sources of Mame32, and your DLL will do the work. This
way you will get rid of stupid license of Mame. Of course it requires
a BIG portion of security and encryption.
I am also very interested in making only limited number of attempts
per game. This can be also checked easily when performing on-line
gaming only.

--
AleyKeprt@bigfoot.com

Sorry dude, online gaming can be faked as well, you could make an inp
generator that passed what ever security questions you asked the
player to make, then it would send the already cheated recorded inp
(or input commands) downstream in real time to your online server to
play the game and get what ever high score necesary. Plus for the
honest players if you get network congestion, your game could be
ruined. Online security has potential, with several authentication
techniques, but it lacks robust playability.

<p>

The real key in security is to check if the recording was made at the
time the game was played and at the speed at which the game was
played. The only problem with this technique is encrypting the inp
and timestamp/framerates so the "fakement" can't generate the inp
with cheating means. Something that will be pretty secure in Ben
Jos's new mame, MAMETE.

--
churritz@cts.com