Author Topic: General Discussion  (Read 3788489 times)

0 Members and 7 Guests are viewing this topic.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #9480 on: February 16, 2017, 01:59:19 PM »
It was a bad design to use mob name as a base for webm name. Because mobs names may have spaces, while autowebm folder uses spaces as separators to define webms properly. These logics are incompatible.

We can always just use a JSON field for it... that should be perfectly safe. In fact, prolly binding imagename: size to the dict that is already there is a decent bet.
Like what we're doing?

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #9481 on: February 16, 2017, 02:31:58 PM »
JSON does seem to make everything better, code is more sound now as well.

New field is this:

Code: [Select]
        "be_webm_sprites": {"idle": ["BlStar_idle", [200, 150]]},
Where "BlStar_idle" is the name of Ren'Py internal imagetag and [200, 150] size of the webm movie frames. Our code is a lot cleaner with this as well. One thing: we expect "be_webm_sprites" to host "idle"! If the dict exists but is empty, you get a ctd.
Like what we're doing?

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #9482 on: February 16, 2017, 02:46:09 PM »
Code: [Select]
                elif type.startswith("on_darkness"):
                    size = int(target.besprite_size[0]*1.5), 60
                    what = Fixed(target.besprite, Transform("be_dark_mask", size=size, align=(.5, .5)), xysize=(target.besprite_size))
                    if type.endswith("shake"):
                        at_list = [damage_shake(0.05, (-10, 10))]

Using offset here was a bad idea, no matter what values we assign, it will screw us over for sprites of different height and either they are on left or the right side of battle field. Aligning inside of the Fixed seems like a perfect solution that cannot fail unless BE sprite itself is screwed up.
Like what we're doing?

Offline lamoli

  • Hero Member
  • *****
  • Posts: 553
Re: General Discussion
« Reply #9483 on: February 18, 2017, 12:06:26 PM »
Hmm just found a rpg maker MV game that has nice combat animations.. ( well spine movements ) it uses pixi-spine you know about that system ? from a png image containing body part and a json they make character animation like kick/block/idle movements .. well maybe it wont work on renpy..


I could render parts with blender and put them in a single .png then .atlas and .json does all the rotation of any of those part to make animation..
« Last Edit: February 18, 2017, 12:30:32 PM by lamoli »

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: General Discussion
« Reply #9484 on: February 19, 2017, 12:20:00 PM »
It's most likely possible from the viewpoint of code.

From the viewpoint of design if we aim to have more or less animated battle sprites for everyone, then we need simple looped animations for all mobs. Ie we need an artist willing to draw sprite sheets which I can animate, since finding enough free, animated 2D mobs with decent resolution is impossible.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #9485 on: February 21, 2017, 02:20:35 AM »
I am back :)

Hmm just found a rpg maker MV game that has nice combat animations.. ( well spine movements ) it uses pixi-spine you know about that system ? from a png image containing body part and a json they make character animation like kick/block/idle movements .. well maybe it wont work on renpy..


I could render parts with blender and put them in a single .png then .atlas and .json does all the rotation of any of those part to make animation..

There are many option and this will work in Ren'Py but should NOT be a priority... We need you to render a simple pack first. We can move to doll technology later and come up with some idea for battle sprites afterwards.

From the viewpoint of design if we aim to have more or less animated battle sprites for everyone, then we need simple looped animations for all mobs. Ie we need an artist willing to draw sprite sheets which I can animate, since finding enough free, animated 2D mobs with decent resolution is impossible.

Well, not really a priority either, I don't really know why you want to have animated sprites anyway, BE is plenty cool with still images and animated overlays.
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: General Discussion
« Reply #9486 on: February 21, 2017, 05:01:53 AM »
I don't really know why you want to have animated sprites anyway, BE is plenty cool with still images and animated overlays.
Many looped db animations cannot be used as spells. Now it's possible to use them as rare, non humanoid mobs. That's the whole reason  :)
I won't refuse if someone will propose to draw looped sheets for all mobs, but I don't aim for that either.

Finishing matrix dungeon, I realized that we lack something important: post battle screen. In most games player can see experience progression after the battle is finished, with experience bars raising in real time, and even notifications about level ups.

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: General Discussion
« Reply #9487 on: February 21, 2017, 10:18:09 AM »
Yeap, I can't do the real time bars part on my own.

I want to show how a group of chars gets exp after a fight (including arena) or some other event. I use portraits and xp bar from hero profile, the prototype is in the last push.

The idea is to give that screen the amount of xp which every character should get (as a list of numbers), and then the screen shows how bars gradually (for 4-5 seconds) become fuller. They also should reset once character levels up, multiple times if needed.

But I'm not sure how to animate the process in real time.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #9488 on: February 21, 2017, 11:49:17 AM »
The idea is to give that screen the amount of xp which every character should get (as a list of numbers), and then the screen shows how bars gradually (for 4-5 seconds) become fuller. They also should reset once character levels up, multiple times if needed.

This part sounds very tricky... rest is simple, gonna do that now.
Like what we're doing?

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #9489 on: February 21, 2017, 12:43:45 PM »
Yeap, I can't do the real time bars part on my own.

I want to show how a group of chars gets exp after a fight (including arena) or some other event. I use portraits and xp bar from hero profile, the prototype is in the last push.

The idea is to give that screen the amount of xp which every character should get (as a list of numbers), and then the screen shows how bars gradually (for 4-5 seconds) become fuller. They also should reset once character levels up, multiple times if needed.

But I'm not sure how to animate the process in real time.

How badly do we want this? Animated bar from value x to value y in Ren'Py is two lines of code, but we're not talking about from x to y. We're talking taking a very complex leveling system, figuring out (on per character basis) "step" based of difference between old and new xp values, increasing the value gradually over time based on that step, updating state of displayable on every step and on queue, when level updates, running a new animation. All of that need to be positioned according to each individual character.

This is a UDD... any setup in screen/using renpy.show will be too messy. It'll take a good while to setup... I'll think about how to structure UDD best unless you kill this in the meanwhile.
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: General Discussion
« Reply #9490 on: February 21, 2017, 12:59:46 PM »
Yeah, that's why I can't do it on my own  :)

Neat animations can wait until full release, I'll make a simpler version for now.

Instead take a look at label storyi_bossroom. I use there star animation which looks flawlessly as long as I don't change its zoom. And when I do, it looks like it uses wrong anchor or something.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #9491 on: February 21, 2017, 01:04:51 PM »
Oki, I'll update the screen to add a simple animation for now.
Like what we're doing?

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #9492 on: February 21, 2017, 01:21:09 PM »
Instead take a look at label storyi_bossroom. I use there star animation which looks flawlessly as long as I don't change its zoom. And when I do, it looks like it uses wrong anchor or something.

Code: [Select]
    show sinister_star at Position(xpos = 704, xanchor=0.5, ypos=91, yanchor=0.5):
        anchor (0.5, 0.5)
        zoom 0.03
        alpha 0
        linear 1.5 alpha 1.0

using Position is always a mistake, it's there only for backwards compatibility and should never be used in modern code for a number of reasons. You should only look at docs for info, maybe Q&A/Cookbook, wiki is very, very, very old.


Edit:

Also... that is a weird code, there is no difference between at and the instructions below. Internally they will be applied together anyway. More appropriate code might be:

Code: [Select]
    show sinister_star:
        pos (704, 91)
        anchor (0.5, 0.5)
        zoom 0.03
        alpha 0
        linear 1.5 alpha 1.0

but I will check what that actually looks like in a sec :)

Looks good now...
« Last Edit: February 21, 2017, 01:33:38 PM by Xela »
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: General Discussion
« Reply #9493 on: February 21, 2017, 01:36:55 PM »
using Position is always a mistake, it's there only for backwards compatibility and should never be used in modern code for a number of reasons.
Really? I figured it would be the same as "show at left".

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: General Discussion
« Reply #9494 on: February 21, 2017, 01:50:38 PM »
Really? I figured it would be the same as "show at left".

No... you can do:

Code: [Select]
show sinister_star at Transform(pos=(704, 91), anchor=(.5, .5))
which is perfectly reasonable. It would still be weird to do this and give instructions below, you can simply just add everything to the below area. Position is old and sometimes incompatible with modern code.
Like what we're doing?