ChristianDevs Forum

I really wanted to do speedgame this year. But... we're having a baby (yay!) any day now, so probably not a good idea. Now granted it'll never be a "great" time to speed game, but on top of that, I have like 2 or 3 projects that are relatively small that I've been working on for a year or more! So I want to try to get an initial release of one of them as my "speedgame" project.

Since I had already started it, oh, and, the fact that it's not a game... it will be here instead of in the speedgame forums.

So my project to hopefully finish in the next week now (I believe there is a week left in speedgame) is:

Stickimator
A 2d skeletal animation utility.

Features:
- Lightweight (small executable, doesn't require any big 3rd party libraries)
- Easy to use (should be intuitive to create bones, edit them, skin them, animate them...)
- Background image support
- Interpolates animations
- Easily select skins from texture sheet

Download coming soon. This first post will always be updated with latest info.

_________________
Public domain code - use at your own risk!

First WIP screenshot

_________________
Public domain code - use at your own risk!

1. Congradultions!!!
2. the animation creator looks amazing!

_________________
Just got back to programming!

Congratulations! Is this your first?

That Stickimator is sweet.

_________________
My quote: Have I mentioned I love C# and the iPad?
Another quote: Have I mentioned I love the iPad?

Thank you to you both!
No this is our second. It is totally new to us though because we have both been born again and married since we had our first... we're not really the same us any more you know? It's gonna be WAY different then last time...

Texture selection is now there, though it will certainly require tweaking as issues are discovered through actual use. Next to work on: Skinning and Saving/loading.

Can you tell I drew the textures myself?

_________________
Public domain code - use at your own risk!

I like the compact and small-ness of your project. Good luck!

_________________
Internet:~ CPUFreak91$ whois CPUFreak91 && which CPUFreak91 && whereis CPUFreak91 && exit

(Find the easter eggs in my signature and win a prize!)

Thank you! Hopefully compactness will translate to finishedness this time around!

So, skinning is beginning to take form. It's an interesting problem of how to orient the textures to the bones though as there isn't really a single general rule that matches what people expect. But there seem to be 2 general rules so far that make it work.

First of all, if the texture is longer vertically or horizontally depends on how it is initially mapped to the bone. The longer extent is the one that will line up with the bone by default.

Second, the texture should flip along it's axis which lines up with the bone when the bone's orientation crosses over from the left side to the right side.

These rules may not always be the case... but generally, the will be what is expected I believe. For other cases the user will be able to rotate/scale/offset the textures on the bone.

Anyway, it seems during skinning I somehow introduced a GDI leak?! All the raw GDI stuff is at a much lower level than what I've been working, so it's probably going to take some digging into to find the problem - I looked initially but couldn't find anything yet. Everything seems to be released properly etc. Erg.

_________________
Public domain code - use at your own risk!

http://stackoverflow.com/questions/1487950/access-violation-in-wm-paint-not-caught

So, as it turns out, my quick n dirty software quad-renderer has a bug that caused it to throw an access violation (windows SEH exception, not C++ exception), but that exception was getting eaten up.

Now I haven't figured out the direct relation yet, but even when all the proper cleanup is called, somewhere a dc and bmp handle aren't being released/destroyed. No exception, no leak. Here's the kicker... code continues to execute exactly where the exception occurred. No walking the stack back up or anything. So the handle(s) get released, but yet they still leak. It's all very confusing and if anyone knows any other little secrets do tell.

Anyhow, now I know where the real culprit is.

_________________
Public domain code - use at your own risk!

So, I have this library called "Paper". It is a c++ template library which implements various image processing algorithms on any type. The idea was to write an algorithm that could work on mono float images, mono int images, and define classes for 2d and 3d vectors as well as various color formats.

It turns out that there are a few design flaws which make it hard to work with in some scenerios. So, before using it any more it will need some structural reworking (it really needs to have support for type and number of channels instead of forcing you to define a class if there is more than 1 channel).

Now, the quad-mapper used for skinning was here, but instead of debugging it (see previous post) I have decided to jump the gun and integrate LICE for some of my drawing instead. This is cool because instead of spending time writing AA primitive renderers and bilinear-filtered texturing algorithms, I can just work on the application.

http://www.cockos.com/wdl/ has LICE in it. And the cool thing is they just give it away (essentially)!

First thing I noticed, though, is there is no direct way to render a rotated quad. There is a rotated blit function... but it seems to be designed specifically for rotating things which are circular in nature (such as 2d knobs in an audio program......) So, after hacking LICE_RotatedBlit to work the way I want to, and fixing a couple depedency issues so the entire WDL library doesn't have to be included, we're good to go. And now our drawing is beautiful!!!

Next up: Rotating and stretching textures (right now they just auto-orient but you can't modify them) and saving/loading.

_________________
Public domain code - use at your own risk!

So, I see speedgame is over. Congratulations to all who participated! I hope to try at least a couple more out (so far I got to try Lava's and Mene's). As for stickimator:

- HAD A BABY GIRL!!!
- Able to save/load
- MRU list
- Impl flip/mirror skeleton
- Polish texture selection
--- Some code refactoring of edit modes
--- Texture load button on empty texture screen
--- Texture autozooms to full texture view on load
--- BUG: Drawing/moving when not zoom 1.0 is problematic in texture background grid
--- BUG: Fix texture grid funniness on right and bottom...
--- BUG: Drawing area outside of texture grid has problems when drag skin rect there
- Polish input
--- BUG: Multiple problems with losing focus on buttons that are toggleable (vs pushbuttons)
--- BUG: Ctrl/shift/alt not registering when focus not on window and click...
--- Refactor input class to be useable anywhere w/o depending on own framework
- Polish on skinning
--- Able to rotate/scale skins attached to bones
--- Able to offset skins attached to bones
--- Better default skin rotations

There were many interesting problems in the latest progress. Rotating/scaling skins was relatively easy. Being able to offset skins based on a bone's orientation and make it seem natural with mouse movement threw me off for a day though!

In the mean time a nice little c header file has been developing with lots and lots of 2d collision detection functions between 2d primitives. Right now it supports circle, aabb, obb, triangle, line segment, point. Most combinations of collisions are defined, though not all. Hopefully I can release this as a little public domain file for download soon, as finding all the information (and occasionally even working out the problem for myself) for these different types of primitives and assembling them into one place has been quite the chore.

It does not support point of collision and especially not collision response, but it does do a quick basic check for collision, and in most cases it does it fairly efficiently.

Anyway still not ready to let this be downloaded, as there are some really clumsy parts as of yet, but it's definitely getting there....

[edit] Another interesting problem is how to decide the default skin orientations on a bone. It will never be perfect, but what is a good way to guess? It turns out the most common expectation (for me, so far) is to account for whether the texture has greater width or height, as well as which quadrant the orientation of the bone is in, and line the texture up to be projected up and down, as you see it on the original texture sheet.

To the user it looks like it was just basically copied off the texture sheet, while internally the skin is actually being rotated one of 4 ways to a default orientation that looks most natural with the bone and with the greater dimension of the skin.

Next up: Finish polishing up the main view, add z ordering, and a couple other things, and try to get something downloadable for the next progress update.

_________________
Public domain code - use at your own risk!

Sheesh!



- Ok ok so newborn babies take 99.999% of your time. She's so beautiful!
- Refactor menu support into framework helper
- Menu system at least there even if not all commands impl. (like undo)
- Polish bone/skin/bg view
--- Select texture/bone(/joint) to rotate bones
--- Better defaults to see/not see grips/bones, option to turn on/off easily
--- Wrong texture draw order: need internal z order, external push/pull "1" layer with pg up/down or [/] or something
--- Able to PASTE from clipboard a temporary background...
--- Skins need zoom (will happen with input reworking)
--- BUG: Sometimes animation pops when interpolating.
--- BUG: Angle accumulation got messed up?! (Loading duplicated children in frame 1 of all animations except the first one)
--- BUG: Lengths of bones are erroneously in pixel coords, not world coords
--- Mouseover anything makes it semi-transparent to see behind for positioning plus to confirm selection
- Polish texture selection
--- Camera bounds support
--- Scroll when drag past edge (if zoomed in)
- Revamp input system
--- Unify input system, make it context based
--- Program-wide Action system to respond to input mappings (also will make undo/redo possible)
- BUG: New while playing w/textures breaks.
- BUG: Menu handle leak
- BUG: New doesn't really reset everything good. Initial new doc doesn't have default anim either.
- BUG: Load stickimator file with no textures and it tries to load non-existent file (must have been tired that night!)
- BUG: Remove animation while it's playing and everything freezes. Remove while stopped and just as bad
- BUG: Can remove all animations. Should force 1 minimum.
- BUG: Checkbox w/o theming doesn't have transparent bg
- More intuitive properties and controls on the left for the given context
--- Little custom control for a group of props
--- Organize sets of properties for each view
--- Get the properties all functioning correctly
- Document format for ske
- Drag n drop to load files

Ok, so then. Taking a bit longer than I hoped. I'm getting to that burnt-out point I think, and was tempted to set it aside for a while. I realized that's what I ALWAYS do though, and the hard part about a project isn't getting it working, it's completing it. Seeing something, even as small as this, all the way through, is really difficult. We tend to be ready to move on before the completion point.

It reminded me how awesome it is that we're promised God will complete the good work that He has started. Not to be cheesy or anything. I'm serious. Think about it... at the point where we'd be like "Ok, I'm ready to just move on. Maybe I'll come back to this person later" He just keeps on going until it's finished.

So, before releasing, there are still plenty of things that need to be done. UI-wise the little frame-navigation at the bottom needs to be a full-blown time line. Right now all frames are .5 seconds apart. There must be an intuitive, easy, and work-flow-happy way to do this. We need a decent timeline editor.

Aside from that, most everything else is internal. Funny bugs when you Load after you already Loaded once. Button tooltips. Documentation. More thought out rules and restrictions on skeleton building (what happens when you create a loop with your bones??). Undo and redo. Inverse Kinematics. Stuff like that.

We're getting closer!!

_________________
Public domain code - use at your own risk!

Also:
http://achild.wikidot.com/programming contains some public domain c++ that others may find useful. Also note that while functional, prim2d and lil are both quite incomplete.

_________________
Public domain code - use at your own risk!

Ok, an update on the previous post:

For anyone interested there is a small bit of public domain code now available at the above link. It's been available for a little while, but I just finished with unit tests for the 2d collision detection stuff, fixed a number of bugs, and uploaded a stable, working version.

- Prim2d.h - All combinations of collision detection between a few primitives such as circle, line segment, triangle, obb, aabb, and point. Also n-sided poly to n-sided poly collision detection. Plus some basic utility functions (dot product, project/unproject, etc). I must admit that this took far longer to get right than I expected! Source code to unit tests to validate functionality and side cases is also available.
- Interp.h - some basic interpolation methods (bilinear, cubic, hermite, catmull rom, etc)
- Timer.h - WIP multiplatform timing. It's a good starting point, at least, but needs some design changes.
- Event.h - c#-like event handling in c++. Very fast. Template param types, up to 4. Call AddHandler on any number of member functions or regular functions. Call Fire to call them. Treats an event as an object. Can use fastdelegate or std::tr1::function.
- Input.cpp/.h - Subclasses a window and gives input messages through an event callback. Maintains state so you always know which keys are pressed/unpressed, handles mouse-leave as well as maintaining mouse focus if you click and drag out of the client area until you unclick, tracks drag rectangle, etc.

Of course bug reports/fixes are welcome! Use as you please without worry, it's dedicated to the public domain!

_________________
Public domain code - use at your own risk!

Ok, so... this has obviously turned into one of those "it's done when it's done" things. But it is definitely not abandoned! No new screenshot since everything is mostly internal (mostly), or has to do with user interaction more so than the display of the software itself.

I also think I've decided on how to "license" it. I think what I'm going to do is this:
- If you are using this for personal use or for a freeware game, the utility is free
- If you are selling and you are a small team or make less than x amount of dollars per year, you must purchase a license for the number of seats using it, but you get to decide the price based upon what you can/want/are willing to spend.
- If you are selling and happen to be a big firm that makes much money, it is $50 a seat

At least that is the work in progress idea. What do you guys think? (This is all assuming it is worthwhile in others' opinions to use). Besides price and purpose, there is no difference in the product between versions... ie the free version doesn't lose any features to the pro version or anything.

So with that, here is the current "to-do(ne) list"

- Rules and restrictions on skeleton building impl...
- BONE SELECTION RULES
--- If joints show, test against joint first
--- If textures show, test against textures second
--- If bones show, test against bones third
--- Can multiselect joints
--- Can multiselect bones
--- Can multiselect using skins
--- Area selection joints to multiselect - But NOT bones (would interfere with joint area sel)
--- Area selection skins to multiselect
--- Multi-multiselect makes sense on joints (ie ctrl + drag-rect)
----- If drag rect is over joints, they should highlight/swell to show it. Same with mouse over.
----- Since skin multi-select always shows what it WILL look like (unless cancelled), shouldn't joints too?
--- Need way to discern mouse-over from selected with skins? If selected AND mouse over, just show selected?
--- Multi-multiselect makes sense on skins
--- Area drag out of viewport scrolls like texture-edit-mode does
--- L-drag should NOT unselect-all, only non-dragging L-click
--- BUG L-button to cancel WHILE r-DRAGGING is buggy on skins, but ok on joints. Needs fixed.
--- BUG Multiselect skins always hilights one of the joints' labels for some reason
--- BUG Area selection out of viewport crashes
--- BUG Captured mouse out of viewport thinks bone 1 is selected
--- BUG 1) Drag-scroll the workspace 2) [multi]Select something 3) Multiselect something else, but cancel the action. 4) Notice that instead of reverted to #2's state, everything gets unselected!
--- BUG Ctrl+click to unselect skin seems to be a step behind until another button is at least pressed?
--- BUG Multiselect box which scrolls, once released, ONLY selects what is visible on viewport. Should include anything offscreen as well.
- BONE ROTATION RULES
--- Single point rotates around parent
--- Root doesn't rotate, but it can MOVE.
--- If root is selected in multiselect at rotate, ignore it.
--- Multiple points rotate around their parent the same amount as the currently selected --- Shouldn't matter which point you grab in multi-points. Should be same. (BUG right now if grab child point instead of one of the parents)
--- Accum mode: Multiple points do NOT rotate if their parent is selected. Only the top level is rotates (but not the root, even if it's selected)
--- Non accum mode: Multiple points who have parents which are also selected are counted as if they are in accum mode (all points from furthest to closest in chain)
--- Should react to mouse, according to click pos. Ie if click on side of joint's circle
representation, rotations should always be relative to this, NOT the center of the circle!
----- BUG Create another root, but cancel... breaks ALL.
----- BUG Root moving never works the first time you move it from exactly 0, 0
BONE LENGTH RULES
--- Length change shouldn't go to length to mouse... it should go relative to where on bone, skin, or joint one clicked first (try it on skinning and see)
--- Length change on multi-select drags around radius of highest selected parent of clicked point. It accumulates the rotations in all that are selected to get a final length.
--- Root moving needs to be treated differently...
- BONE DISPLAY RULES
--- Not just root at 0, but all true roots should look like root at 0 does
--- none - skins: normal, no alpha joints: red, normal size
--- mouse over - skins: alpha + tint joints: swell
--- selected - skins: alpha value joints: green
--- multi-select - skins: alpha value TO BE if not cancelled joints: swell, color-to-be

- BUG: Crashing when try to load texture that doesn't exist from ske file
- BUG: Floating point values with 'e-' or 'e+' in them fail on props
- BUG: Load file with skins, 1st skin selected but not loaded in props
- BUG: What happened to skin zoom??
- BUG: Text printing alpha is 0. Problem when used for textures. Manually adjust post-render.
- BUG: Ok. What happened to skin scroll?
- BUG: Click abone, then a joint from different bone to move. Old bone is see through, not new.
- BUG: Load after load, property panel gives value-out-of-range error.
- BUG: Skinning mode transparency bugs
- BUG: Shouldn't be able to hide skins in Skinning mode!!!
- BUG: Grabber circles in skin mode affected by Z-order. Should always be on top.
- BUG: Creating extra root joint has incorrect zoom application
- BUG: Multi-multiselect with dragbox erases prev. multiselect
- BUG: Cancel click for area-select in texture mode just restarts area-select at current mouse pos
- BUG: Click-drag a not-yet-selected texture aabb will grab it's left-handle instead and adjust, instead of move
- BUG: Clicked texture is sometimes not the one selected in property panel. Why?
- BUG: Deleting bone/joint crashes and doesn't properly create another root
- BUG: Mouse-over bone just stopped working *sigh*
- BUG: New-Document doesn't reset camera
- BUG: Skin mode mouse-over-skins highlights other skins and other bones.
- BUG: Bone mode selects skin in z order (correct) even if overlapping with already selected skin (not correct - should "grab" the already selected skin in this case)
- BUG: Load file from MRU throws instead of giving message and being graceful
- BUG: Delete ALL created textures crashes
- BUG: Cancel creation of bone from root with no other bones present deletes root
- BUG: Crash when attempting to load non-existent textures in release builds
- BUG: When removing points, draw order is forgotten.
- BUG: Flicker of texture pane when init app
- BUG: Undo accelerator won't work in edit boxes AND as global accelerator...
- BUG: Redo (ctrl-y) when action is delete, while editing label name for the to-be-deleted thing, leaves edit box but loses everything else.
- BUG: Property sheet bugs
--- BUG: Edit controls on property panels don't support copy/paste?
--- BUG: Props fail on exponential notation floating point numbers
--- BUG: If edit control on prop sheet has focus when exiting program, we crash
--- BUG: Double-click on text to hilight when no focus doesn't work. Have to triple click.
--- BUG: Hit close button while edit box on props has focus fails
--- BUG: In multiselect, when changing length/angle, props doesn't reflect real-time state
- Show missing textures on skeleton in useful way
- Any grab circles (joints, skin-grab-circles, etc) should have outline in black to differentiate if they happen to be over a texture of the same, exact, solid color.
- Selected bone should also be translucent... not just mouseover bone (until it becomes selected)
- Ctrl-drag sizer on skin should do it while maintaining aspect ratio
- Accelerator keys support
- Allow texture creation through shift+lbutton OR just rbutton
- Delete bone or joint should warn user what is about to happen
- Go back to texturing quads instead of rotatesprite for skinning (use own)
- Auto detect textures (happens on texture load)
- Better tinting of skins on bone edit mode to better represent draw order while still indicating difference between unselected, mouseover, and selected
- Delete joint message affects all frames only happens IF MORE THAN 1 FRAME AND ANIM!
- Menu stuff for initial release (not feature complete!)
--- Autodetect textures manually (re-autodetect them)
--- Basic file handling
--- Flip/Mirror
--- Delete (need action instead of direct-effect within main view)
--- Undo!!!! and redo.

I plan on writing up a couple articles/journals on issues I've run into while developing this (issues useful in most areas of tools-dev), which I'll probably post to gamedev.net since I believe anyone can host a member-journal there now. Let you guys know if/when that happens. God's peace be with you all!

_________________
Public domain code - use at your own risk!

I finally moved past "think I've decided" to "made a decision". It is just going to be free. (as in beer? speech?) How about... free as in the gospel!

Many factors were considered:
- Don't I want to make money off this?
- Will people even take it seriously if it's free? (too often we take stuff far more seriously if there's a price involved [insert state of Christianity in the USA vs China comment here as well] )
- If it costs money, who should be my target demographic?
- *I* think it is turning out to be a very good tool. Will it even meet others' standards though?
- When you give a little, people tend to want much more than if they had paid for it (they value their expense higher... goes with point above) (we all do it)

I finally realized... this isn't a product I care if people take seriously (ie. actual game studios). In fact it was never meant to be sold in the first place. It was hard to see clearly once I started realizing it had potential (in my opinion) to become a business-oriented thing for me.

In other words... it's purpose was never to make me money (or even try). And it was never meant to be targeted to game studios or even well established indies. It's time to re-erase those thoughts from muddying up the direction it's going.

On that note using it to help make games will be fun... I hope it's ready (and available to any who may want to use it) by speedgame.

_________________
Public domain code - use at your own risk!

So, I'm not entirely sure if this thread is actually interesting to anyone, but it is nice to use this to track the history of developing Stickimator. I guess it has become sort of a journal for myself. Anyway, thanks for letting me at least use this space to do so

With that said, wow it's been almost a year since the project was resumed, and almost 1 1/2 years since I started it altogether. Sheesh. One of the issues about hobby programming, of course, is that that's sort of how it has to go. There are plenty of days where absolutely no time gets spent on it. There are occasional days where, you know, a few hours get spent on it (usually deep into the night, just starting a session after 12 or so, which can be exhausting when one has to get up early the next morning of course).

But a great deal of the time, this project gets 15-30 minute time spots - per day.

This is why, in the last month, the frame/timeline control has almost been completed. There is a flip side to this though! I get to spend more time thinking about it (when not thinking about other stuff of course). Why is that good? Because software (good software) always develops iteratively (sp?).

You work on the prototype. You try it out. It works, but doesn't feel right. You have to think about what would be better. It can't just be a blind process. Make changes, rinse and repeat. Even with the timeline, there were many problems which took considerable amount of thought. "How can this provide functionality x, not feel awkward, and not break feature y or make it feel awkward?" Really, this stuff takes time, considerable thought, and multiple iterations, whether it is an animation application, a game, a database application, or something else.

I also noticed there is a new software called "Spriter" that is being worked on and received full funding and then some through kickstarter - within 6 days. $25k. It looks awesome! It was also kinda depressing. "Why didn't I go through kickstarter and advertise too?" "I wish I knew and was close to an artist that could show off Stickimator's capabilities" "I could have been first." And everyone is commenting "I was wondering when someone was finally going to make something like this".

It's amazing how quick ones thoughts can head in a very bad and selfish direction. I totally lost focus for a minute there. And I was definitely jealous of the attention they are getting. I don't want to feel any of these things. For one thing these thoughts keep invading when I never meant to take it that direction in the first place. For another thing, haha, Stickimator may not even be any use to others - it could have totally failed it's goals for the niche it is trying to fill. Only time will tell. Most of all, I don't want to be driven by greed (Not saying they are - I'm saying I was. I mean $25k and THEN SOME is quite a lot of money to me, not to mention sales of the actual product which will follow making them a business), and I don't want to be driven by a desire for the attention someone else is (rightfully) getting. I want these things to go away from me.

Anyway I checked it out, and Spriter uses a very different workflow and principles than Stickimator. It was interesting to see that some of their solutions to certain problems are very, very similar to the solutions I came to. It was also very interesting to see just how different some of our solutions were. The biggest difference is that Spriter seems to be developed from an artist's perspective, whereas Stickimator is driven from a programmer-who-stinks-at-art-but-wants-to-have-good-art-in-his-game's perspective.

Finally, there were 3 positive results of my internal battle:
1) I have been losing motivation on Stickimator again (nobody wants to work on a timeline control for 4+ weeks straight, whether it's 8 hours a day or 15 minutes a day). My bit of a jealousy remotivated me heheh
2) I re-(re)-realized the original purpose to focus on - I want a tool that will help me a make a cool game, hopefully one which will attract an artist to help one day. And if it's truly useful, I want it to be freely available to others just in case it is could be of use to them.
3) I donated a few bucks to Spriter, because it's really awesome what they are doing, and seemed like a good counter-action to my negative thoughts and feelings.

There are so many cool features I want to add (inverse kinematics, multiple texture sources, movie-background referencing for animation...), but for the 1.0 alpha release, the timeline was the only major feature left needed.

After it and a few bugs are squashed, a link will be posted and we'll see if we can get some feedback! Thanks again for letting me use this place to pour out my heart and mind.

_________________
Public domain code - use at your own risk!

I havent so far quite understood what your stickimator is, but now you mentioned that it is somewhat similar to Spriter and done from programmers point of view.

That grabbed my interest and for first time it seems like I might have some idea about what you are doing.


So can you now describe what stickimator is?


For when i saw spriter i was thinking it looked like something that could be handy, but I didnt quite get how to actually use it on programs, that is it easy enough to use inside programs.

Is Stickimator goingt to be easy enough to use in programs and can it be used by any program?

achild, I know what you mean. I've had some of the same sentiments with the project I'm working on. Had a meeting with the leadership yesterday to show them v0.1 (first draft) of the web app on working on here at the Bible College. It's super overwhelming since I'm learning how to develop as I go. But God reminded me yesterday the reason I'm doing this. It's not my project, but it's His. He will provide the knowledge and skill I need and/or the people with that skill to complete this project in His time.

Same goes for your project. God has a purpose for this project and maybe He will use it to help someone develop a game that might get people thinking that maybe there is something to this Jesus person. Who knows?

Edit: Where can I try it out? Do you have a binary or is it open-source?

_________________
Change is a vector. You can have all the change in the world, but if it isn't going the right direction watch out! http://techonamission.com

Hi bugala! I will try my best to explain how it works.

As you know, usually when you make a game with animation, you have a series of sprites that are displayed one after the other and it looks like motion. The idea behind Spriter and Stickimator (though executed in a different ways) is to have parts of a character which can be moved and rotated to form the animation. In the case of a human or animal, those parts may be the had, body, and limbs. It can be anything though, really.

Stickimator itself works by creating 2d "bones" to form sort of a skeleton of the thing you are making, and then you attach a skin texture to some or all of the bones. Then you can move the bone around, and if other bones are connected to it, they move too. As the bones move, so do the skins attached to them.

You create keyframes out of these different poses, and when you play the animation it interpolates what the character looks like at any given point, making it look smooth. (In your game, you would not draw the bones... just the skins)
-----
Just as you create the graphics in a separate program, then pull them into your game, this will be similar. You create the animations which are output to a file format, and you pull that into your game.

In order to use it in your game, you have to be able to read the file format, and display what it tells you to display. For this, you will need either a library (if you use C/C++, Python, XNA, etc), or a plugin (if you use GameMaker, Unity, etc).

I plan on releasing a C or C++ library to interact with these files. This library will not render graphics for you. Instead, it will return all the information needed by the rendering engine you are using, so that it can be plugged into any game code easily. Hopefully, if anyone likes Stickimator's workflow and finds it useful, people will create (and contribute) libraries for other languages and plugins for other frameworks so it can easily be used with whatever they use to make games.

I hope that explanation helped. Let me know any details I wasn't clear on

GorillaMcD: Thanks for the encouragement - I don't know Ruby and probably won't learn it any time soon but I am interested to check out your work when I get a chance. Also Stickimator is not ready to try out yet... very close to an alpha release but not quite yet.

_________________
Public domain code - use at your own risk!