Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: kkurbjun (r24062): Accept a form of FS #10561

Re: kkurbjun (r24062): Accept a form of FS #10561

From: Karl Kurbjun <kkurbjun_at_gmail.com>
Date: Fri, 18 Dec 2009 15:25:01 -0700

On Fri, Dec 18, 2009 at 4:43 AM, Paul Louden <paulthenerd_at_gmail.com> wrote:

> Alex Parker wrote:
>
>> So can we/you/they/someone not just change the brick size to be relatively
>> the same as before? Would that result in the improved aesthetics + the game
>> play remaining as was?
>>
>> Alex
>>
> It would, yes. But with the release coming up, and no clue when someone
> with any aptitude at bitmap editing is likely to step up for such a thing, I
> think the gameplay should be restored to what it was before at the moment
> until the full fix is in.
>

Now that I am a bit less frustrated with Paul for trying to make a mountain
out of a molehill, let me explain the ways that this argument is flawed and
the reason that his threats to revert the change if I do not are out of
line:

1) First this argument started purely on principal without even trying the
change. The change was not tried before he started to complain about a
minor gameplay difference.

The complaint about a "considerable" gameplay change was made before he even
tried the game with the modified screen height. This argument is now
continuing with a mis-understanding of what the change did and how the game
works (currently and before) and how development works.

2) This gameplay "rule" is made on an assumption that the game plays the
same on all targets. There is also the complaint about a general gameplay
changes.

This assumption is simply incorrect. The game does not play the same on all
targets, there are a number of differences that are just as small an
insignificant as this. Till all of those issues are fixed, the point that
the game should play /exactly/ the same on all of the targets is moot.

This includes a number of differences that alters gameplay. For example on
the Gigabeat F/X/S the images are not scaled properly for the screen width
or height even before this patch was committed. This significantly changes
the gameplay (much more than this patch might) but no one is out there
fixing the problem or even discussing it. Fixing this could be done at the
same time that the brick heights are scaled for this patch: the improvement
is simple.

On a number of targets the paddle widths are not properly scaled for the
screen size. This takes the same scaling effort that improving on this
patch would require.

The brick height ratios are not the same on all of the targets either for
reasons beyond this patch. In some cases this is unavoidable if you want
bricks that are distinguishable from each other.

In cases like the Gigabeat F/X/S the brick heights were not scaled properly
even /before/ this patch was added (according to this "rule" that Paul
speaks of).

This means that the brick heights and widths were "wrong" (according to this
supposed gameplay "rule") on at least 50% of the targets this effects before
this change was made.

Not too long ago someone added some new powerups that truly, significantly,
changed the gameplay unlike this patch; where were the complaints then?

3) The fix that Paul wants just requires scaling the bitmaps for a couple of
targets. This is something that I (or anyone else; maybe Paul for example),
could have done in all of about 10 minutes per target that requires it (only
a handful). Instead this discussion is wasting everyone's time on the
mailing list based on a principal of how the game should work on a few
select targets. The collective effort reading this mail is more time spent
than the minor improvement being complained about.

4) I would also like to point out that SVN is an incremental process and is
a working copy. This patch improves the experience on portrait screens and
the minor gameplay difference is a moot point till all the other
discrepancies are fixed.

Furthering that improvement takes little time that a non-programmer can do
now that this change is in place making it easier for /others/ to contribute
to the project.

5) This patch has been in the tracker for 4 months. In that time there was
never any discussion about the brick heights.

Paul, or anyone else for that matter, had plenty of time to comment on
this. Not once did I hear a mention of the brick height scaling. The fact
that there is now an attempt to make a big deal out of a small gameplay
change seems inconceivable to me.

6) Development is done on: "Find an itch and scratch it". Clearly this
patch was submitted for an itch from another programmer. I agree with that
and feel that improves the game on portrait screens even if there is a
/minor/ gameplay difference.

If someone else finds an itch to scratch they are free to do so by improving
on what is already there instead of harassing development about minor
issues.

7) There is no hard and fast rule that the gameplay or user interaction
cannot change for plugins. This is not the core that we are talking about,
and there have been plenty of situations that the plugins have changed
significantly. Not too long ago there was a big deal about the Clock plugin
with the user interaction changes that were made. The general consensus was
that anyone is free to work on them as they see fit.

8) I am not disagreeing that scaling the bitmaps may add a minor
improvement, but I feel that Paul's threats to revert a change on something
that he has not contributed any significant development to is out of line
especially since the crux of Paul's argument is flawed.

Again, If the patch is reverted the bricks heights and widths will still be
wrong (according to this supposed gameplay "rule") on at least 50% of the
targets that this change effects. If a fix is needed for those targets
anyway according to this supposed gameplay "rule" then we are already at
break-even with the patch in there.

I still dispute the validity of the idea that the gameplay cannot be changed
from what it currently is. If that is the case maybe we should all just
stop development since that would be a change in the user experience.

-Karl
Received on 2009-12-18


Page was last modified "Jan 10 2012" The Rockbox Crew
aaa