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

Two larry types #79

Closed
Quintus opened this issue Jun 13, 2014 · 22 comments
Closed

Two larry types #79

Quintus opened this issue Jun 13, 2014 · 22 comments
Assignees

Comments

@Quintus
Copy link
Member

Quintus commented Jun 13, 2014

As already discussed in #62 (comment) this might be interesting. One "doom" larry that kills you immediately, and one "normal" larry that just downgrades. Currently, larry immediately kills everything nearby.

Vale,
Quintus

@datahead8888
Copy link
Member

@Quintus, did you suggest making a common class from which both Larry and Doom Larry inherit, or did you suggest having the doom larry class inherit from the regular larry class?

@Quintus
Copy link
Member Author

Quintus commented Jun 8, 2015

datahead8888 [email protected] writes:

@Quintus, did you suggest making a common class from which both Larry
and Doom Larry inherit, or did you suggest having the doom larry class
inherit from the regular larry class?

I think the DoomLarry class should inherit from the Larry class, because
if you make a Larry class from which you have an OrdinaryLarry and a
DoomLarry derived, the OrdinaryLarry class would serve no purpose,
because it doesn’t specialise on the Larry common class in any way.

Graphically, this is what I recommend:

       Larry
         ↓
      DoomLarry

And this isn’t useful:

       Larry
      /     \
Ordinary    Doom
  Larry     Larry

In which way would OrdinaryLarry be different from Larry in that last
graphic?

Vale,
Quintus

@datahead8888
Copy link
Member

If we had both OrdinaryLarry and DoomLarry inherit from a Larry class, it would probably have to be an abstract class that eliminated common code between the other two. I like the idea of having DoomLarry inherit from the regular Larry class, though, since it implies Doom Larries are overriding the normal Larry behavior (and doing something evil :P ).

@Bugsbane
Copy link
Member

Ladies(?) and Gents,

I present to you, Doom / Evil Larry:
action

And here is a tar.gz of the frames.

@datahead8888
Copy link
Member

Bugsbane's graphics for Doom Larry are now committed in the NewLarries branch, which has been pushed to github. I will do another commit later for the settings files that also attribute Bugsbane as the author.

@datahead8888
Copy link
Member

The basic purpose of having Doom Larries is so that, if they explode, they will kill Alex in one hit.

What if we also did either of the following:

  • Fireballs destroy regular Larries. What if they only caused Doom Larries to begin their count down?
  • Doom Larries might move slightly faster than regular Larries

We also might consider using a bit different sound effect when Doom Larries explode, if we can pick a good one. A different explosion effect (once implemented for regular Larries) would also be cool.

@Quintus
Copy link
Member Author

Quintus commented Jul 2, 2015

Look for sounds on freesound.org, they have quite a lot of them.

Fireballs destroy regular Larries. What if they only caused Doom Larries to begin their count down?

This seems irrational. If the ordinary larry directly explodes, the doom larry should also, as it is an even more dangerous version of the ordinary larry. I realize that the player might experience a surprise if he throws lots of fireballs around, but he’ll be more careful next time.

Doom Larries might move slightly faster than regular Larries

I’d be fine with this. Recently, I noticed furballs jump if they come over a little edge (if the edge is not higher than they’re tall). These doom larries could do that also.

Ah, I want to implement new features as well...! But the SFML port needs to be done...

Vale,
Quintus

@datahead8888
Copy link
Member

This seems irrational. If the ordinary larry directly explodes, the doom larry should also, as it is an even more dangerous version of the ordinary larry. I realize that the player might experience a surprise if he throws lots of fireballs around, but he’ll be more careful next time.

The idea was that Doom Larries are strong and withstand the fireballs a little better, but you are correct this would make them less difficult for the player.

Recently, I noticed furballs jump if they come over a little edge (if the edge is not higher than they’re tall). These doom larries could do that also.

I think you had said this was a bit buggy for the furballs. We definitely need some more jumping (and flying) enemies, however. It won't be interesting to have every single enemy just be a walker.

@datahead8888
Copy link
Member

This is what doom larries will look like in game:
doom_larries

@Quintus
Copy link
Member Author

Quintus commented Jul 4, 2015 via email

@Bugsbane
Copy link
Member

They look a little big to me. Personally I'd like to see them come up to Alex's chin, rather than being the same size

@datahead8888
Copy link
Member

Alex was not large (ie having eaten a size berry) in this screenshot. We would also have to adjust the gray Larries if we make this change.

@Bugsbane
Copy link
Member

Ah yes. I hadn't considered that asked was small. As long as they're smaller than big Alex, is say we're fine.

@Quintus
Copy link
Member Author

Quintus commented Aug 1, 2015

@datahead8888 State of this? Maybe you want to remove the “needs info” label?

Vale,
Quintus

@datahead8888
Copy link
Member

In the NewLarries branch you can currently create and save Doom Larries in levels, and they kill Alex in one hit. They are also spawnable through scripts.

The remaining work is to find and add a special Doom Larry explosion sound effect (if anyone else happens to find one let me know) and then remove disused code. I was not sure if special code needed to be added for a Doom Larry explosion scripting method; I did not see one for regular Larries. I'm not sure if this will get done in the next 1-2 months, but I guess we'll see.

@datahead8888
Copy link
Member

Here are some explosion sound effects I came across:
http://opengameart.org/content/action-shooter-soundset-wwvi
*big_explosion.ogg
*synthetic_thunder_short.ogg
*volcano_eruption.ogg

If we find one we like, we might be able to use it for the Doom Larry explosion sound and/or the Larry explosion sound.

@ghost
Copy link

ghost commented Aug 4, 2015

Hmm, those are very long. I mean, it's not like those walking bomb dudes
are missile warheads.
How about bombexplosion.ogg or rocket_explosion.ogg instead? At least
for normal Larry.

Partially related: #402

Am 04.08.2015 um 20:31 schrieb datahead8888:

Here are some explosion sound effects I came across:
http://opengameart.org/content/action-shooter-soundset-wwvi
*big_explosion.ogg
*synthetic_thunder_short.ogg
*volcano_eruption.ogg

If we find one we like, we might be able to use it for the Doom Larry
explosion sound and/or the Larry explosion sound.


Reply to this email directly or view it on GitHub
#79 (comment).

@datahead8888
Copy link
Member

The Doom Larries will kill Alex in one hit, while the others will not. Thus a bigger than normal explosion sound effect might make sense. We'll have to see how the length sounds in-game, though.

@datahead8888
Copy link
Member

@sauer2, I found that bombexplosion.ogg sounds like a rock making a thud. For the rocket one, I found rocket_exhaust.ogg, but this one sounds more like a rocket streaming overhead.

I've set it to big_explosion.ogg for Doom Larry and left it as the existing thunder sound effect for regular Larries. We can always change it with another commit if there is disagreement.

@datahead8888
Copy link
Member

PR #460 is filed for these changes.

@datahead8888
Copy link
Member

There seems to be a pre-existing bug in which Larries do not give points at all. I inherited this bug when finishing Doom Larry. I intend to fix it for both types of Larries.

@datahead8888
Copy link
Member

The scoring issue is fixed. The PR cited above is ready for review again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants