About this project
"I am a huge fan of Spine. The tool is absolutely amazing. Looking forward to having Torque 2D utilizing Spine!" -Michael Perry, GarageGames
"Spine is great! Finally a huge void in our 2D content creation process is filled; something no other animation tool on the market could do for us." -Moritz Voss, HandyGames
"Spine is the 2D skeletal animation tool that game devs have been hoping for. It's well designed and well engineered." -Matt Rix, Unity Futile
Spine is a 2D skeletal animation tool for game development and other animation projects. It features an intuitive workflow to rig and animate skeletons, a multiple-timeline dopesheet for retiming and tweaking animations, and powerful exporting capabilities.
Spine currently has all the features necessary to use it in production, except for loading and using the data in your games. For each game toolkit, we need to write a runtime library that loads the animation data and draws the animations. Currently this is only done for libgdx, and this is where we need your help.
We set out to build games, but instead we’ve been working full time on Spine for many months. We would love to add Spine runtimes for Unity, cocos2d, Corona, and others, but we also need to move on and build our own games. Funding this KickStarter will allow us to postpone our games a little longer to add support for additional toolkits and enable Spine to be used in all kinds of games. With your help, we can build the runtimes to match the same level of quality as the rest of Spine, and official runtimes will be kept up to date as Spine evolves.
Our Kickstarter has been funded! This means we will implement Spine runtimes for these game toolkits:
Unity: Futile and 2D Toolkit
You can download Spine and give it a try right now for Windows, Mac, and Linux. All of the most important features have already been implemented and hopefully this gives you confidence that we can deliver the runtimes we promise.
We hit our goal for the four runtimes in just 3.5 days! The gaming community's response to Spine has been really fantastic! We've already added support for Corona and are working on the other three toolkits promised in the original goal: Unity Futile, Unity 2DToolkit, and cocos2d-iphone. In the meantime, we have been thinking a lot about what to do for stretch goals.
We've received hundreds of requests to build Spine runtimes for all kinds of gaming toolkits. We would love to build official runtimes for everyone's favorite toolkit, but this would take an astronomical amount of effort. We have thought long and hard about what our stretch goals should be for Spine and finally decided we could do better than listing a bunch of game toolkits, each of which only a fraction of the gaming community cares about. We think we have come up with a way to make everyone happy.
We have stretch goals to implement generic Spine runtimes for specific programming languages. A generic runtime does everything except the game toolkit specific drawing. It loads the skeleton and animation data into an object model that makes it easily accessible, for example to pose the skeleton, do procedural manipulation, changes skins, etc. To support a game toolkit, all that needs to be done is add the game toolkit's rendering to the generic runtime. This allows the gaming community to easily make high quality runtimes for almost any game toolkit. The key part of this plan is that the core of the runtimes are officially supported and maintained as Spine evolves.
We have also added stretch goals for some really awesome features. When building Spine there were many things that couldn't make it into version 1.0. We choose from all those as well as features suggested by the Spine community. We are very weary about feature bloat, so we have been careful to choose the features that provide the most value when taking into account Spine's workflow. We also took into account how feasible the features are and we only chose those that we know we can implement in a timely manner. It is very important to us that we don't let you down!
We are extremely excited about Spine's future and really hope we can meet many of these stretch goals. Please help us bring Spine to the next level and make it the most amazing tool for game development!
Touchpad support Spine was designed for use with a mouse. When using a touchpad, for example on a laptop, Spine can be difficult to use. This item adds a touchpad friendly input mode. We may not be able to support multi touch touchpads, but will be sure that the app is perfectly usable with a touchpad.
Additive blending for slots Enables the images attached to a slot to be drawn using additive blending, for toolkits that support it.
Adjustable playback speed and framerate Enables slowing or speeding up playback so animations can be tweaked easier. Also allows the framerate used in the timeline to be changed.
Resizable dopesheet and tree Enables the dopesheet and tree to be resized by dragging. This allows a lot more to be seen on larger screens and is especially great for tweaking keys in the dopesheet.
Import for exported skeletons and animations Allows data in the same format Spine exports to be imported back into Spine. This allows data to be brought into Spine from other programs. Also, data can be exported from one project and imported into another.
A Spine runtime in the Lua programming language. This enables easier development of Spine runtimes for Gideros, LÖVE, Moai, and others.
A Spine runtime in the C++ programming language. This enables easier development of Spine runtimes for cocos2d-x, Kobold2D, KoboldTouch, SFML, and others.
A Spine runtime in the ActionScript 3 programming language. This enables easier development of Spine runtimes for Flixel, Starling, and others.
A Spine runtime in the C# programming language. This enables easier development of Spine runtimes for MonoGame, XNA, and others.
Onion skinning draws a shadow of the frames before and after the current frame to give some idea of the previous and next motion of an object. This is very useful when refining animation movement by adding keys between major poses.
Keyable draw order Allows draw order to be changed and keyed in animate mode. This allows a slot to move in front or behind other slots during an animation.
Duplicate bone Makes a copy of a bone, any child bones, and any slots and images. This is useful when creating skeletons that have multiple similar bones or body parts.
Bone snapping When moving a bone, this snaps to the start and end of other bones. This makes it easy to build skeletons where the bones match up exactly.
Disable rotation/scale inheritance This allows rotation or scale to not affect a child bone. For scale, this means additional keys are not needed to avoid a child being scaled. For rotation, this allows a child bone to not rotate with the parent, for example a rope hanging from the end of a crane.
These are boxes attached to bones, similar to how images are attached. The boxes represent where the skeleton can be hit. In your game you can easily test for hit detection.
Integrated texture packer Enables Spine to pack individual images on to larger images for more efficient use by your game toolkit.
Graph presets Allows graph curves to be stored so they can easily be applied to other keys without needing to define the curve again.
Multiple slot color modification Allows multiple slots to be selected and have their color changed all at once.
Multiple drag and drop for slot draw order Allows multiple slots to be selected under Draw Order and dragged to a new position all at once.
This adds an "Events" node to the tree where named events can be defined. These events can then be keyed in animations. This allows events to be triggered in your games, for example to play a sound or spawn a projectile or particle effect at a specific time in an animation.
Slot image chooser A popup for a bone that shows thumbnails for all images for each slot. Choosing a thumbnail sets a key to change the slot's image. Note changing a slot's image in an animation is already possible, this is just a faster way of doing it.
Animated textures This allows image with a common prefix to be treated as a single images. They are given a framerate and are displayed as an animation. This is much easier than keying each image change.
Backgrounds This adds a "Background" node to the tree where images can be dragged. These show up behind the skeletons in the editor. This can give a better feel for how the skeletons will look in-game. It can also be used to animate skeletons for use on top of a specific image, for example to animate a skeleton climbing on top of objects in the background image.
Ripple animation Repeats a dopesheet channel for the rest of the animation. Without this, repeating an animation manually for a whole animation is very tedious.
Dopesheet overview This is a dopesheet item that represents all keys in the animation. This makes it easy to select, scale, etc all keys.
Disable dopesheet channels This disables a dopesheet channel so it won't affect the animation. This is useful for disabling portions of an animation during tweaking.
Free-form deformation allows an image to be manipulated by moving the four corners or points along the edges. The image will distort appropriately. This reduces image changes, meaning a lot less art is required. It allows for much more powerful animation beyond just animating bones.
There are many tools for working in 3D that can be used for 2D, though they tend to be very expensive. Custom plugins need to be written to have a sane workflow for 2D skeletal animation and to extract the data for use in your games. You must write your own runtime for your games to make use of this data. These tools tend to have an enormous feature set and you must be careful to avoid accidentally using features that aren't supported in your runtime. All this is a lot of work up front to get the custom plugins and runtime working, and the end result is a clunky workflow riddled with gotchas.
There are not many tools dedicated to 2D. We will mention a few here.
Adobe's Flash is ubiquitous on the Internet and can be used similar to Spine. It is not dedicated to skeletal animation though, making the workflow somewhat tedious. Data is exported as XML, but there are no standard runtimes for game toolkits, you have to write your own.
BrashMonkey's Spriter began development 15 months ago. We were initially thrilled when Spriter was funded on Kickstarter 9 months ago. We posted our feedback on the Spriter forums when we found it lacked official runtimes, a multiple-timeline dopesheet, tweening curves, and separate keying of scale, rotation, and translation. After a couple months we decided that Spriter may never have the features and workflow we envisioned, and that is when we decided to build Spine.
Spine focuses on having an efficient workflow from start to finish. The best way to compare Spine with other software is to build a simple animation with each and put them in your game while noting how easily the tools allow you to tweak and refine your animations.
Spine animation has many advantages over traditional raster animation:
Reduced art assets Characters can be animated in many ways without requiring additional art.
Small data size Spine animations are tiny, enabling hundreds of animations to be used throughout a game to bring it to life.
Faster development Creating and making use of animations is easy, even programmers can do it.
Animation reuse All of the same animations can be reused for characters that look completely different if they use the same skeleton.
Procedural manipulation Modify the skeleton or animations at runtime to react to game situations.
Smooth interpolation Interpolated keyframes mean animation is as smooth as the framerate.
Animation blending Transition smoothly to a new animation by blending it with the old animation.
Spine makes it fast and easy to bring your entire game to life!
We've been working on Spine full time for a long time. We are excited to have completed all the major features it needs to be used in production and we are looking forward to seeing what the gaming community can build with it. There are many features we wanted to implement but were unable to include in the first version of Spine. We have been careful to avoid feature bloat and keep the workflow in mind, but these features would be very useful. If this Kickstarter does extremely well, we would love to implement these!
Event timeline Allows timing arbitrary events during animations, eg to trigger sounds or particles.
Bounding boxes Rectangles attached to bones for easier hit detection.
Onion skinning Shows the previous and next animation frames so it is easier to see motion over time when designing animations.
Procedural animation helpers Utilities to make procedural animation easier, eg a bone that is always rotated toward a point with rotation constraints.
Box2D integration Control physics entities from animations or animations from physics entities.
Image attachment animation Animate an image's scale, rotation, and translation separately from the parent bone.
Freeform deformation Animate an image using a lattice for deformation.
Inverse kinematics at runtime Allows for fewer keyframes and more flexible procedural animation.
Animation layers Have an animation extend another animation and add keys.
Animation mixer Similar to the dopesheet, but for blending and timing animations for cutscenes and larger animations.
Risks and challenges
For each game toolkit, building a Spine runtime consists of implementing the loading of the data, the math for properly transforming the bones and images, posing the skeleton based on the animation data, loading and drawing the art assets, and providing a nice, easy to use API. Each of these tasks is done differently in the various game toolkits and programming languages, so we must carefully research how to best integrate the Spine runtime.
Because Spine makes it easy to animate everything in your game, it is expected that many animations will be used at once. This means it is important that the Spine runtimes perform well. Animations and bone transformations need to be efficient. Texture atlases need to be supported. Drawing the images should be fast, batching used if possible, etc. Performance testing needs to be done for each game toolkit to optimize the runtime. For toolkits that run on multiple platforms, this must be done on each platform.
We have a combined total of 23+ years of industry experience building software, gaming libraries and tools (eg, libgdx), and designing concise, clean APIs (eg, Kryo, KryoNet). We've spent an enormous amount of effort building Spine with great attention to detail and high standards for quality. We want to build the runtimes to match so that the entire Spine experience is seamless and pleasant from start to finish.Learn about accountability on Kickstarter
Support this project
- (30 days)