Crowd-sourcing animation?

[x4000]

Cheers!  I really appreciate it -- all of it.  Of all the people who have contributed to the beta, I don't think anybody else had a singularly larger impact than you.  The suggestion-acceptance-rates don't really show that, but the whole refactoring period in November was all sparked by your commentary.  And the same has been true of a great many other issues and ideas, since, as well.

I just had realized I hadn't taken a chance to thank you for that yet, and so wanted to let you know what an impact you've made.

[Bluddy]

Thank you. That means a lot to me.

It's a real pleasure on my end interacting with you guys. I absolutely love how transparent you are, to the point that we use the same bug management tool that you guys are using -- it's an amazing experience, as others have already commented. And I love how you were able to take my original remarks - which were probably said in too harsh of a tone - and use them constructively. I also really appreciate that you and Keith aren't afraid to try something completely new, or to not follow the predefined genre constructs. It takes a lot of guts and creativity to do that, especially when you're not backed by a huge company. Your passion for what you do shines through, and it's been really cool to be a part of the process of making AVWW.

Anyway, onwards to AVWW 2.0 (as soon as you've recovered from the craziness, that is)!

[keith.lamothe]

(as soon as you've recovered from the craziness, that is)!

Ah, no, you've got it the other way around: it's the craziness that makes all this happen, we just need to correct our momentary lapse into sanity!

And yes, thanks for all the help

[x4000]

Cheers, Bluddy.  I don't have anything more to add, in particular.  But you've really rapidly become an integral part of this community and we're both really happy to have you here.

[tigersfan]

Cheers, Bluddy.  I don't have anything more to add, in particular.  But you've really rapidly become an integral part of this community and we're both really happy to have you here.

Make that three of us.

[zebramatt]

Wow, this turned into a bromance, huh?

I'm happy for you guys 

[x4000]

 

[nanostrike]

Is it possible to modify/substitute in new, custom character models?  I know there was a post about replacing some of the in-game art, and I was wondering if it was possible for characters too?

[Coppermantis]

Given that all the character art is just PNG images in runtimedata/images then I would say yes.

[zebramatt]

Yup, and you can add it as a texture pack, so you're not replacing anything permanently (and it's persistent across releases).

You know you can install this as a texture pack, right?

Texture Pack Support

There is now a dropdown in the Graphics tab that allows you to select from any installed Texture Packs, if any are installed.

Here are the instructions for how to create texture packs if you have an interest in doing that:
To add a texture pack, simply add a folder here in the AVWW/RuntimeData/TexturePacks folder.
The name of the texture pack in the game will be the name of the folder. So if you make a folder called BobsTextures, that's what it will show up as in the game.

HOW TO REPLACE A TEXTURE USING THE TEXTURE PACK:
Inside your texture pack folder, simply duplicate the contents of the Images folder that you want to replace. Don't bother moving over images that you aren't doing custom versions of -- the game will first look into the active texture pack folder and then will look into the base images folder if nothing was found.
So, for instance, if you want to replace the keyboard cursor (normally located at AVWW/RuntimeData/Images/Misc/KeyboardCursor.png) you would add AVWW/RuntimeData/TexturePacks/BobsTextures/Images/Misc/KeyboardCursor.png.
That would alter the keyboard cursor, but no other parts of the game. You can do that for as many or as few images as you like.

HOW TO REPLACE A PARTICLE EFFECT USING THE TEXTURE PACK:
Inside your texture pack folder, make a Configuration folder. Then make a Particles.xml file that is a copy of the main Particles.xml file in AVWW/RuntimeData/Configuration/Particles.xml.
Simply make <g pattern="Fireball"></g> entries for particle effects that you wish to change. Don't worry about trying to do them all -- just do the ones you're actually making changes to. The others will load from the main Particles.xml file just fine, but your custom particle definitions will selectively override whatever you wish.
Did you know? When you have the game open, you can hit Ctrl+F4 to reload the Particles.xml files at will. That way you can make a small tweak, hit that key combo, and then test your change immediately without having to restart the application.

TIPS:
Generally speaking, you need to keep the images to the same size and dimensions as the original. Any wildly different image sizes won't look at all correct in-game, especially when it comes to sprite dictionaries (animations).
That said, when it comes to things in the Backdrops and Ground folders, those can be set to pretty much whatever size since they are repeating tiled graphics.

[Bluddy]

I have a question. When you load textures from disk, do you store/cache them as PNGs in memory, or do you translate them straight to textures?

[x4000]

I have a question. When you load textures from disk, do you store/cache them as PNGs in memory, or do you translate them straight to textures?

It's not something we handle directly; however, unity loads them into a texture in unmanaged memory.

[Bluddy]

I have a question. When you load textures from disk, do you store/cache them as PNGs in memory, or do you translate them straight to textures?

It's not something we handle directly; however, unity loads them into a texture in unmanaged memory.

That's what I thought. The thing about this is that this is very wasteful of memory, since Unity converts each PNG to a texture. This is why you get such extreme memory allocations for the graphics. What you really want to do is cache the PNGs in memory yourselves -- just store the data. PNG compression is great for the type of graphics you have, so if you store them in memory, you get massive savings. What you want to do is only convert the PNGs to textures dynamically (ie feed them to Unity) when you need them.

[x4000]

I have a question. When you load textures from disk, do you store/cache them as PNGs in memory, or do you translate them straight to textures?

It's not something we handle directly; however, unity loads them into a texture in unmanaged memory.

That's what I thought. The thing about this is that this is very wasteful of memory, since Unity converts each PNG to a texture. This is why you get such extreme memory allocations for the graphics. What you really want to do is cache the PNGs in memory yourselves -- just store the data. PNG compression is great for the type of graphics you have, so if you store them in memory, you get massive savings. What you want to do is only convert the PNGs to textures dynamically (ie feed them to Unity) when you need them.

Nope, quite the opposite.  The compression of PNG may be great, but to use it at all requires decoding it and sending that to the GPU.  Wasteful of CPU cycles and RAM.  Unity stores the textures in a lightly compressed format that can be directly read by modern GPUs.  I forget the exact one it's using, but it's one of several that are standard in pretty much most games.  Storing the PNGs natively and then converting them once per frame to something the GPU can draw would probably be lucky to get you one frame a second on a lot of computers.

And anyhow, it's all beside the point because we're not able to change things at that level with the engine in the first place; if you'd like the unity engine recoded you'll have to talk to them rather than me.

[Nanako]

It seems like the problem here is that you've used frame by frame animation. WHY ?

I'm writing a game in flash just now, and it stood out to me immediately that this was a bad idea to do animations. Luckily flash has a built in feature (though perhaps you could code something similar) for 2D armatures. I have an image of a character's arm, head, torso, etc, that are pieced together into the whole, and all animations exist simply as transforms of that armature. one character is a set number of images that will never change no matter how i animate it. I'm not exactly alone in doing something like this, either, it's quite common in many flash games.

flash does have support for runtime armatures as well, which incorporates a lot more math, but that wouldn't be necessary. to me it's purely an authortime tool for making animations that move and flow convincingly, and keep the resource use low.