Larry the Bomb Boss

[datahead8888]

This is a task to create a Larry the Bomb Boss

Concept Discussion:

• http://smc.quintilianus.eu/viewtopic.php?id=45

Tasks

• Decide name - "Mega Larry", "Larry Boss", etc.
• Decide rules
• Code logic in C++
• Do we need custom scripting? We may want more than one way to defeat Larry depending on the level!
• Either scale the existing Larry sprite (short term or permanent) or generate an svg

[datahead8888]

I would like to try this change when I finish the cerr one.
I will probably have to ask a lot of questions at that time, though.
@Quintus, this would add a nice touch to the 2.0 release if it were included, since a third boss would really help wrap up the new world(s) we're adding with new features.

[Quintus]

Then take a shoot on it ;-). File a PR for it (with "WIP" if it isn’t ready) and I will flag it for the 2.0.0 milestone.

Vale,
Quintus

[datahead8888]

I was assuming I should finish the other thing I was working on before filing a PR, but I could file one for this if you want. I wasn't sure if the 2014-07-31 feature freeze you posted was for suggesting new features in github or for finishing the implementation of features. I seem to remember you saying we'd all discuss what's feasible once that date passes. There is a good chance I will not finish this change by July 31st. It would help to give a better impression for a milestone 2.0 release (a finale), but in reality it's not absolutely necessary. It will, however, be critical to have new levels in the main game demonstrating all of the new features for that release.

[Quintus]

I wasn't sure if the 2014-07-31 feature freeze you posted was for suggesting new features in github or for finishing the implementation of features

I quote shamelessly myself from the SMC forums:

In the second phase, we will stop implementing new features (or rather, if we implement further ones, they won’t go into SMC 2.0.0) and instead concentrate on bugfixes. Therefore, when the second phase is entered, the maximum number of features in SMC 2.0.0 has been settled on. If a feature then turns out to be too hard to fix, we may still decide to remove it from the game again, either postponing it for the next release or dropping it alltogether.

That is, what has not been merged into devel after that day (→ 2014-07-31 23:59:59.9999 UTC) will not get into 2.0.0. Those things that got into devel, no matter how buggy, will get into 2.0.0 unless they appear too hard to fix. On 2014-08-01 I will branch off the release-2.0.0 branch, into which no new features are merged (they go into devel instead, which is then heading for the next release).

As a practical consequence, I will go through all open feature PRs marked with "WIP" a few days before the feature freeze and ask their respective authors if they consider their code stable enough for being merged now. If they agree, I will merge this before the feature freeze, if they don’t I won’t and the PRs will go into the next release (or whatever release when they are finished).

This means, you can always file a PR. And if you want my comments on your code, you are highly recommended to do that, because I won’t follow all the commits in your own repositories. If a PR is marked "WIP" this means it is not ready to be merged; if it doesn’t it is meant to be merged as soon as possible.

Vale,
Quintus

[datahead8888]

This probably won't be going in version 2.0 then. Thanks for the explanation.

[datahead8888]

@Quintus, is ed3fdf2 a good place to look to understand what's needed for this change?

We had talked about using the existing Larry image and scaling it to a larger size for now. Would you prefer to clone a copy of the svg image so that an artist can easily swap it out later, or would you rather configure the xml for this boss to link to the regular Larry image?

This task will probably run pretty slow for a while. I need to focus on learning scripting / some level editing, and school is about to start in a couple weeks.

[Quintus]

We had talked about using the existing Larry image and scaling it to a larger size for now. Would you prefer to clone a copy of the svg image so that an artist can easily swap it out later

The SVGs are here:

• https://github.com/Secretchronicles/SMC/blob/devel/drafts/game/mrvertigo27/level/enemies/larry.svg
• https://github.com/Secretchronicles/SMC/blob/devel/drafts/game/mrvertigo27/level/enemies/larry_plain.svg

Rescaling is just exporting it in another size. SVG does not care about pixels, it’s a vector format. Swapping out the image can later be done always. If you want to work on the SVG itself, then yes, a new SVG for the larry boss would be required.

Vale,
Quintus

[Quintus]

is ed3fdf2 a good place to look to understand what's needed for this change?

You should probably just look at the implementation of cLarry in its current state rather than focusing on a single commit. There have been some code changs later.

Vale,
Quintus

[datahead8888]

 If you want to work on the SVG itself, then yes, a new SVG for the larry boss would be required.

No, I just had meant whether we wanted to create a placeholder (carbon copy image pasted through Windows/Linux) for an artist to swap it out later if and when desired. By rescale I had only meant to rescale it within the SMC application image configuration. If someone decides to edit an SVG for this boss, then they would rescale or do other things with it in Inkscape.

[Quintus]

No, I just had meant whether we wanted to create a placeholder (carbon copy image pasted through Windows/Linux) for an artist to swap it out later

Yes, that would probably be good rather than using the larry images directly. This way no code changes are necessary for graphics change later (unless of course the larry boss has more/less frames later).

Vale,
Quintus