Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MARIO: New engine #932

Closed
wants to merge 19 commits into from
Closed

MARIO: New engine #932

wants to merge 19 commits into from

Conversation

Retro-Junk
Copy link
Contributor

Worst game ever for them, just another engine for ScummVM!

This is the long-awaited engine for a game that is not allowed to be named.
But today we break that rule and speak it aloud:

Plumbers Don't Wear Ties

... don't you agree? Either way, here you have it.

At this moment PC version of the game is playable few with minor glitches. Most noticeable one is broken mouse cursor. 3DO version will be supported in the future.

PS. By the way, this is not a joke.

@dreammaster
Copy link
Member

Really, there's not that much to review for this engine, given it's absurd simplicity. Code seems reasonably formatted. Probably best to remove the readme.txt

@bluegr
Copy link
Member

bluegr commented Apr 1, 2017

At first, I thought this was a joke, not only because of the size of the engine, but because of a total lack of video support or scene hotspots.... but then Strangerke told me that the game itself is a series of images, and you get multiple choice questions in each scene, which lead to other scenes.

There's not much to say, apart from the fact that this is the smallest engine ever! :P Best non-April fool's joke! :D

There are some leftover debug statements scattered within mario.cpp, which should be removed. And the Mario & Luigi joke is priceless :)

break;
}
if (_curChoice < kMaxChoice) {
debug("Accepting mouse click at %d : %d , choice = %d", mousePos.x, mousePos.y, _curChoice);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover debug code

}

Common::String name = dirname + "/" + filename;
debug("%s : %s", __FUNCTION__, name.c_str());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover debug code


void MarioGame::playSound() {
Common::String name = _scenes[_curSceneIdx]._sceneName + "/" + _scenes[_curSceneIdx]._waveFilename;
debug("%s : %s", __FUNCTION__, name.c_str());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover debug code

}

void MarioGame::stopSound() {
debug("%s", __FUNCTION__);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover debug code

}

void MarioGame::showScene() {
debug("%s : %d", __FUNCTION__, _curSceneIdx);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover debug code

}

void MarioGame::updateScene() {
debug("%s : %d", __FUNCTION__, _curBitmapIdx);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover debug code

}

void MarioGame::changeScene() {
debug("%s : %d", __FUNCTION__, _curChoice);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover debug code

}

void MarioGame::processTimer() {
debug("%s", __FUNCTION__);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover debug code

}

int MarioGame::getSceneNumb(int sNo) {
debug("%s : %d", __FUNCTION__, sNo);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leftover debug code

@bluegr
Copy link
Member

bluegr commented Apr 3, 2017

Regarding the debug code: a debug level could be used (e.g. 1), so that the debug messages do not appear all the time in debug builds

@criezy
Copy link
Member

criezy commented Apr 9, 2017

I have no issue with this engine being merged, but maybe it should be renamed first? Mario is fun as a joke, but I would prefer something that makes more sense, such as 'plumbers'.

@PaulGilbert
Copy link
Contributor

Seems like it should be ready to merge in.. the engine was renamed by Strangerke a week ago to something a bit more sensible.

@bluegr
Copy link
Member

bluegr commented Apr 18, 2017

IMHO, all of the commits should be renamed with the PLUMBERS prefix, otherwise this would look bad on commit history. I guess that this can be squashed into one commit, since the engine itself is really really (really...) small

@dreammaster
Copy link
Member

md5's idea is a good one.. in this case, given the engine simplicity, I too think it a good idea to squash the history into a single PLUMBERS: commit.

@criezy
Copy link
Member

criezy commented Apr 28, 2017

This PR has now been around for almost a month and I have seen no objections to it being merged. If nobody object or ask for more time to discuss it within the next two days I will squash all the commits as suggested by @bluegr and @dreammaster and merge it on Sunday.

@bluegr
Copy link
Member

bluegr commented Apr 28, 2017

No objections from me, if the commits are squashed/renamed appropriately :)

@wjp
Copy link
Contributor

wjp commented Apr 28, 2017

I was hoping this PR would die on its own. I don't want to be associated with this game, think it's in incredibly poor taste, and think it would be a mistake to merge it.

@bluegr
Copy link
Member

bluegr commented Apr 28, 2017

Well, this game is meant to be a spoof. People who would be interested in this game, would be able to play it. I find the game itself wacky and weird, but people who would like to play it, are free to do so.

I don't believe that engines should be rejected just because some of the ScummVM developers don't like the games that they support, unless there is a valid reason for the games themselves to be extremely out of scope of ScummVM (e.g. shoot'em'up games).

@dreammaster
Copy link
Member

I have to agree with md5. Whilst I concur with wjp that the game sounds pretty simplistic and silly, I don't think peoples' tastes should be a criteria for whether an engine is accepted. I personally dislike some of the games already on ScummVM.. I don't handle severe/pyschological horror very well, and from what little I've heard of IHNM, playing it would probably scar me for life. But I accept that it has it's place, and some people seem to enjoy it.

In fact, in the case of this engine, it really bears some significant similarities in genre to Voyeur.. after all, Voyeur is more or less just static images and movies simply keyed at different times and places in the mansion, with what you select/see determining the story (albeit with a little randomized selection at the start of killer). PLUMBERS is more simplistic and doesn't have FMV, but I don't see any other major fundamental differences that would allow Voyeur but preclude PLUMBERS.

@lotharsm
Copy link
Member

lotharsm commented May 1, 2017

In my opinion, ScummVM is all about preserving game history and make sure that the games are playable in the future.

I agree that PLUMBERS is a really bad game. But it is a game and thus should be preserved, even if it might be one of the worst games ever made (which might make the game somewhat interesting). But it's still a game that might even have some fans and we have an engine for it now.

If you don't like it, that's perfectly fine. I don't think that it has a bad effect on the ScummVM project if we offer support for "bad" games, it more likely shows the diversity of the project.

In general, I support merging this engine to the project.

@Strangerke
Copy link
Member

I have fixed this morning the mouse cursor, which means the engine is now complete. I didn't add save/load, despite obviously it would be pretty easy, because the game may be finished in a reasonable time if you enable the skip screen option in the debugger. Reasonable = less than 2 minutes. The history still has to be fixed, which I guess would take me a matter of minutes if I was a bit more at ease with git.

Now I'd like to add a couple of notes about this engine.

The game supported is the (super-super rare) PC version, which is fully censored (at the opposite of the more recent (rare) 3DO version which shows a nipple in the censorship screen (I don't remember more than that, and I still wonder the use of the censor screen, maybe it's yet another of their jokes), and the ONLY animation played in the 3DO version isn't present in this version (thus the lack of video player).

Now, the negative point: even I have very mixed feelings about a merge.

On one hand, I love this game because it's completely surrealist and because it's clearly a joke. I told that thousands of times and I sincerely believe it, as it makes me laugh each time I play it. So obviously, now that an engine is complete, I would hate to see it rot.

Now on the other hand, despite I'm a crazy inclusionist, I have to admit that this game is not an adventure game. It's clearly a visual novel and it really doesn't fit our current genre scope.

So my mixed feelings are easy to understand: I'd love to see it merged so it doesn't rot, and I sincerely don't want it to be supported, or at least not as long as a game genre scope exists.

@criezy
Copy link
Member

criezy commented May 2, 2017

As you may have noticed, despite what I wrote last week I have no yet merged the engine. This is because I wanted to give myself and others the time to think and comment about it. For several reasons I also have mixed feeling about a merge.

When I discussed merging the engine with sev this weekend he mentioned that scummvm-misc might be a better place for it, and I agree. One issue though is that scummvm-misc was apparently never migrated to git and still resides on sf.net/SVN. Also this would not prevent the engine from rotting (I would not be surprised for example if the Gargoyle engine doesn't work with the current ScummVM source code). Having those engines in one place though might help to increase visibility and find developers to keep them up to date. And despite the expanded scope of ScummVM i feel there is still place for a separate repository to house engines that do not quite fit into the ScummVM scope.

@digitall
Copy link
Member

digitall commented May 2, 2017

Can we take a pragmatic view here... An pretty much complete engine has been offered for merge, it is tiny and is disabled by default so will only be built for nightly builds or if users wish to build it themselves.

Artistically, it is a awful game, in the same way that "Plan 9 From Outer Space" is an awful movie, but there are cult fans of this and tastes vary.

While I tend to agree that PDWT could be considered a Visual Novel or some similar genre, this is a "No True Scotsman" argument and Myst and several other games with minimal inventory or FMV could be considered similar.

Personally, I would suggest merging and leaving it disabled from release builds for now.

@criezy
Copy link
Member

criezy commented May 2, 2017

Despite some reservations, I have decided to merge the engine. Not merging it would have meant letting it die slowly (scummvm-misc is a graveyard at this point), and there seemed to be a majority wanting it to be merged.

At the very least it will serve as a very simple example of a full engine.

@criezy criezy closed this May 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants