Jump to content

Mike at BrashMonkey

Administrators
  • Posts

    2,975
  • Joined

  • Last visited

  • Days Won

    230

Posts posted by Mike at BrashMonkey

  1. There's no easy way to flip an entire animation in the current build of Spriter, but features like flipping and rotating animations or full frames will be showing up in the near future...along the way to Spriter 1.0.

    Amazingly, you're the first person to ask for this...I assume mostly because any full Spriter implimentation for a game engine would support flipping and rotating the animations on the fly in the game.

    cheers,

    Mike at BrashMonkey

  2. Hi janimator00,

    1) Deformation is definately something Edgar and I are both very much excited about and intend to get in after the release of 1.0. We can't guarantee how soon, but its definately one of the big ones on the list of future features.

    2) Easing for the tweening is another one that will definately appear as soon as we can get it in. We know how important that one is.

    3) Dynamically drawing in sprites from within Spriter for the sake of creating placeholder "sketches" of the sprites you need for new animations has been a features I've dreampt of since my very first clunky Spriter prototype... This is another feature we want to get in after 1.0 is released...its just a matter of time after we get in all the already listed 1.0 features.

    4) I think I know what you mean by "offsetting limbs"...You mean offset their timing from one another by being able to have seperate key frames per object (bone or sprite) which you can easily drag along the timeline independantly. If thats what you mean, you'll be happy to hear this is another feature we alswys planed on and finally had a cance to put in.. unless I'm mistaken, it should be in the next build release.

    thanks everyone for all the great suggestions,

    Mike at BrashMonkey

  3. Hi jayderyu,

    Spriter is to create highly optimized animations for games and will allow to easily and visually edit some game related data...like triggering sounds, variable changes, collision rectangles, image points (such as for anchoring or spawning from those points) etc. But Spriter is not a game engine. It's meant to be used with game authoring software.

    1) Spriter will soon have its feature we've called "Character-Maps".. This will allow you to easily tell Spriter or your game engine to swap out single images or entire folders of images with alternate ones, or just hide them all together. This will be great for anything from making a character sometimes have a hat or cape, and some times not, or to give them new armor or weapons, or completely change one character to another using the same animation data. It's up to the Spriter user to organize their images neatly onto logical folders... but Spriter will eventually have features to let you move images to different folders from within Spriter to make it super easy to reorganize as you go. The number of Sprites used in modular animation techniques (such as Spriter uses) will always be drastically fewer (and smaller) than with full frame animation.

    2) It is possible we'll support vector art some time down the line, but if that happens, it will be some time after we've implemented and perfected a long list of other features we have planned... so, its possible, but not guaranteed, and if ever, not for quite some time.

    3) This is Character Maps again.. You'll simply tell Spriter that you want to create a "Character Map" for an "entity" (an entity is a set of animations). A character map is a list of images or folders of images, and what images they should be swapped out for. You will need the same exact number of sprites representing the new clothes as sprites with the original clothes...angles has nothing to do with it. If the default character has 8 arm images with a short sleeve blue shirt, and you want a version with a long sleeve red shirt, you'll need 8 long red sleeve images exactly the same as the blue short sleeve images.

    4) We'll start by creating new tutorial vids as soon as possible...once the new build is released, and try to release videos for each new feature introduced... then, as soon as Spriter 1.0 is released one of our top priorities will be to make full documentation and tutorials for it.

    5) We're not sure exactly when Spriter Pro 1.0 will be ready , but it should be some time Q1 of 2013. The next build (which is long overdue) should be released within a matter of days.

    Thank you very much for the support and excitement. We're just as excited and working very hard go get Spriter fully featured and super easy and flexible to use ASAP.

    cheers,

    Mike at BrashMonkey

  4. Yes, Laufman.

    Hold Cntrl while dragging a new image from the files palette and it will populate that new sprite across all key frames.

    Many more features to make workflow easier and of course much more and better doccumentation and vidoes are very high on our priority list once Spriter 1.0 is ready. Thanks for your patience.

    Mike at BrashMonkey

  5. It will eventually, and in fact, any particular Spriter plug-in could be made to do that even now, But of course, it would require you to make sure the bones are set up the same, with the same names etc, between animations.

    We can't promise when it will be built into Spriter itself, and of course then the creator(s) of each plug-in would need to impliment it as well.

    -Mike at BrashMonkey

  6. Hi Everyone,

    Mike at BrashMonkey here.

    As some of you might remember, from early on, when it was our intention to have first party plug-ins created for many popular game authoring systems, Torque support was near the top of our list. As we could not afford to hire an engineer outright, we had struck a deal with a skilled programmer who was nice enough to work on Torque2D support for Spriter in his spare time for the extremely modest rates I could manage to pay him out of pocket as well as the promise of a share in the revenue generated from the eventual sales of the pro version of the plug-in.

    As mentioned in a previous thread, the amazing speed and enthusiasm with which members of dev communities are creating free and open Spriter support for countless authoring systems proved to us we needed to rethink our pursuit of 1st party plug-ins all together.

    To those ends, Mike Ness has generously agreed to share what he'd accomplished so far with the Spriter and Torque communities so anyone interested can contribute to its development and so that full Spriter support can be available for all Torque 2D users as soon as possible!

    Now I'm passing this post over to Mike Ness (the engineer) to fill you in on the technical details. Thanks so much Mr. Ness!

    ---------------

    http://www.brashmonkeygames.com/brashmonkey/spriter/T2SpriterDemo.zip

    Thanks Mike. The source archive contains a modified copy of the Fish demo that I was using as a test case. The Spriter code is in game/gameScripts and consists of three main files: spriter.cs, spriterData.cs, and spriterEntity.cs.

    spriter.cs contains some helper methods to load SCML files, create entities, etc.

    spriterData.cs contains the Data class which is responsible for reading and storing the SCML file data.

    spriterEntity.cs contains the Entity class which uses the Data class to build an entity and attach it to a scene.

    Currently the code only loads the first mainline animation frame and displays them as a set of t2dStaticSprites. No animation is implemented at this stage.

    My plan had been to continue developing these torque scripts in order to implement the whole of the Spriter functionality without the need to recompile Torque. Later, I planned to write some C++ classes to take advantage of increase performance when recompiling the engine was appropriate. Integration with TGB was also in the back of my mind, but lower on the priority list. The next obvious step forward with this code would be to implement the animation system.

    Feel free to use (or not use) this code however you wish. When I started this project I was new to Torque, so perhaps there are more efficient ways to accomplish the things I've done here--if so, use them! And I look forward to seeing what the community does with this project.

    Thanks,

    Mike Ness

  7. Hi rintoulj,

    Thanks for the kind words and welcome to Spriter!

    All the features you're asking about (using precreated animations as guides for key frames and a way to auto space key frames to specified FPS) will end up in Spriter some time in the relative near future.

    For now, you can of course put a temporary sprite in all key frames and set it to display your reference frames. (I'm doing that myself atm)..but obvioulsy once theres an automated way to set up actual guide images for frames it will rock!

    For the timeline think...right now t he only way to space it out is manually, but this too will change within the next few months.

    Most of the really complicated features for Spriter 1.0 are nearly finished, so cool features like these which will greatly improve workflow will soon be our focus.

    cheers,

    Mike at BrashMonkey

  8. Hi Redwyn,

    Thanks for the kind words. We're determined to make Spriter the ultimate 2d game animating tool. We've only just begun adding the features which will make Spriter a joy to use and a huge asset in any games production tool kit.

    That said, no matter what tools you use to create 2d animation the fact remains that the more a game's point of view is in perspective (such as top down, isometric and the view you're using) the more work and expertise is required from the artist.

    For any view like this, when animating a humaniod character, you can no longer rely on 2d bones and the simple rotation of the same limb images across the screen to create natural movements such as walking. Many images need to be created representing the limbs in actual forshortenedperspective.

    By far the best way to acheive high quality results in these types of games is to create and animate 3d models, then export the finished animations as sequential images that you could then not only load in as guides to "rotoscope" over to create he final, optimized animations in Spriter, but also you can cut them up to get the seperate body part images you'll need.

    Tpically what you'll be reusing alot in this perspective are both the centralized parts like heads, chests etc, but also limb parts which repeat position in natural movement (like the arm swinging forward and back during a walk... the same images can be used for movement in both directions).

    Furthermore, you'll notice in many classic games which use this perspective, the characters are symetrical, so entire frames can be reused, flipped to finish the second half of an animation (such as walking) or even standing at idle is actually half a person with a mirror image to make the second half.

    So, long story short, games that use these angles are much more work for the artist...which is why you inevetibly see games like this use drastically fewer frames of animation, symetrical characters etc. I'd suggest you get your hands on free 3d humaniod posing and animation software like DazStudio asap and start to learn how to animate in 3d (at least to use as a guide and then "paint over")

    I hope this info was helpful.

    cheers,

    Mike at BrashMonkey

  9. Hi Peach,

    Once all critical Spriter Pro features are finished and stable, time will be spent to create a low-res pixel-art friendly mode and set of features for Spriter. Part of this will be making sure grabing, manitulating and seing tiny images and bones is not a problem.

    For now, did you see up at the top of the canvas window there are options to hide or lock bones or sprites. This will help you avoid grabbing images when you want to grab bones.

    cheers,

    Mike at BrashMonkey

×
×
  • Create New...