next »

[Scott]

Basis released!
http://www.basis2d.com

What is it?
Basis is a tool for creating 2d animations and integrating them into games. It is designed for 2d skeletal animation. We plan on implementing very specific features for traditional animation (hand-drawn, pixel art, whatever), and eventually, level and world creation.

 

Features

• SDK
  • Full documentation
  • Working examples
  • Growing for more frameworks, libraries, and languages
• Textures
  • Auto detection
  • Packing
  • Multiple atlas support
• Game Interaction
  • Event triggers
  • Markers/attach points
  • World unit to pixel calibration
• Animation
  • Hierarchical IK with unlimited depth and multiple locks
  • Traditional, simple, FK
  • Inline easing curves
  • Sprite export supporting animated gifs, avis, sprite sheets, and image sequences
• Editor
  • Full undo/redo
  • User themes
  • Fully localized
  • No external dependencies, small footprint
  • 3+ years of iterations on workflow efficiency
• Much more to come!

All feedback is welcome. And thank you to everyone for your support! A lot of our encouragement came from here.

This post will continue to be updated as Basis progresses. For more in depth progress see later posts.[/list]

[yuotta]

This sounds interesting...can it do anything with Sprites?

[Scott]

Can you give me an example of what you mean?

You can certainly create a single bone and attach a sprite to it, and then everything available can be done to that sprite in a sense - rotation, scaling, stretching, etc. It would allow you to create attachment points and hot spot to the sprite.

There was also the thought to also do bendables... a single skin attached to a series of bones so that when you bend and rotate them there is no seem at the joints.

[edit] There will also be a frame based image export (png, tga, whatever) as an example (with code) once it supports import/export plugins.

[yuotta]

This sounds really efficient! I would love to see more so I can ask more questions :D

[Scott]

re: ripple mode in the timeline/frame control.

Note to self - when you realize that eventually accumulating floating point errors are going to absolutely break functionality regardless of clever workarounds, and that you will need to use integers internally at some point, don't try to "get away with it until later".  

(This is in relation to the arbitrary length of time between any 2 keyframes, for anyone wondering. On playback it really won't matter. In the editor it will be a problem.)

[DarthDie]

Yeah I also have to say this is really intriguing, and it'd certainly help to solve my problem of trying to figure out the most efficient way to attach various items to a character.

Do you have any kind of time frame for when it might be released, even if the release is a beta or some such ?

[Scott]

I'm hoping for mid-June for a public alpha. This, of course, depends on how much time I can find to work on it. Self-motivation for it is very high, but there are simply other areas in my life that must get higher priority  . (church, family, job, ...)

It is curious though - are more people finding interest in this for what it can add to a more traditional sprite creation workflow? (versus using the 2d skeleton to aid in animation)

[Scott]

Stickimator is being developed iteratively. Ie once a feature is implemented, it gets tested for how it "feels" and how efficient it is, and then it is improved upon. Sometimes this is a simple tweak. Other times I realize I went about it all wrong, and perhaps other parts of the software even need re-examined. I don't believe a single feature has been "it" the first time around heheh.

I've hit one of those snags where something should honestly take you, like, a day, but 3 weeks later you're still a day away and getting a bit demotivated/frustrated.

[yuotta]

Hm well stay with it for sure it seems like it could be really cool! I say sprites because I find that animating sprites has never had a standalone product for it. 2-d Bones, IK, are in other programs already.

[Scott]

Alright!  So I'm finally making some headway here. I hate being stuck on the same thing for a long time. I recently was able to find a multi-hour time slot during the daytime (read: not already mentally exhausted) to just work on this and it made a huge difference. Thank you to God, my wonderful wife, and my kids.

It's funny after 15 or so years of programming the things one can learn - sometimes for the 4th or 5th time. For example - the most recent design issue Stickimator has faced is how to handle keyboard modifiers to mouse actions.

Let's say you're holding down ctrl + some mouse action. This does something different than it would without ctrl. You have completed you action, and you simply let go of ctrl and the mouse button to complete the action. However, it triggers the action that would have occurred without control!

Okay so the first issue is if, in the middle of an action, you press/unpress ctrl, do you
1) change mid-action what you're doing? (yes - every software I can think of does this)
2) does the action-change (a) apply immediately (needing visual feedback immediately) or (b) does it wait for a mouse move so that users who let go of the key fractions of a second before the mouse button don't get any unexpected surprises? Not to mention it doesn't really feel wrong to have to move the mouse again after pressing a different modifier in order to see the difference.

I'm in favor of 2a over 2b because, again, that's how most other software works. Maybe it seems like a no-brainer, but you honestly don't realize it's even a thing requiring thought until you have come to the situation. When you have logic for I'm-doing-something handled mostly in mouse-move, it requires extra thought, design, and code to ensure keyboard modifier press/release is visually represented immediately so there are no surprises and so it "feels" right! That's the hard part - which one did you expect to happen without actually having to think about it?

----- The latest list of completed tasks
- ADDED: Tools->Split command
- ADDED: Ctrl+alt+drag to move any pin without moving children with it
- ADDED: Ripple edit support in timeline control (global command 'R' key)
- ADDED: Tooltips to toolbars
- ADDED: *Version 2 of file format. Complete overhaul of internal data representation to
  support more advanced features in the future
- ADDED: *Time unit overhaul. Arbitrary integer tics used instead of floating point seconds
- ADDED: Load files through command line (drag-n-drop file to app icon)
- ADDED: Right-click cancels all timeline actions correctly
- FIXED: A number of bugfixes not listed here since it's not really public yet
- TWEAK: Internally, no more concept of "joints" and "bones". Everything is a "pin".
- TWEAK: Many other usability tweaks not listed here

(*) These required a great deal of internal changes that were very time consuming

[Scott]

So one completely useless cosmetic "feature" in Stickimator is the custom windows gui wrapper. The deal here is to have flicker free everything-controls as well as transparency where stuff is see through. But I also want native controls when possible.

We start with every control having the "clip children" property to knock out many flicker issues. Problem is now some of the in-built ways to get transparency won't work, because the parent isn't drawing that part normally.

So the next step is I actually have an explicit "copy background rect to dc" command that can be triggered by any child control. Also we hope for it to work on everything from XP up. Note this isn't the only method of doing this, and I'm sure it's not the best.

Now, for windows controls, consistency is an issue. Usually it's just a matter of googling the right combination of key words to find the correct method. For buttons we use WM_NOTIFY, NM_CUSTOMDRAW, and CDDS_PREERASE. Slider control is the same except we use CDDS_PREPAINT, and CDDS_ITEMPREPAINT if we want to remove those tics (though there are other issues with a Slider control because it seems to cache a bitmap internally too...). Toolbar is the same as Slider control, minus the caching issues.
---
For the combo box though! Starting in Windows Vista I think, the combobox has been updated. See the new problem here:


Every combination of WM_whatever did not seem to fix this. Finally there was a method that seemed to show promise. It involved taking control of the drawing process in WM_PAINT as suggested by some places and passing a DC to wParam in a little chain command. Results:

The main issue there not being losing the border (we were gonna redo it... or something) but losing the uniformity (sp?) of the drop-down button and the text display! It's old style white box background!

After attempting many other things, it turns out combobox handles drawing the background different than any other control I've dealt with thus far. It actually sends WM_PRINTCLIENT to the parent in order to get background information. Huh! Nothing else would work here... so the final solution seemed to be to handle WM_PRINTCLIENT in any parent (all come from the same base class) and copy it's own background. Finally!


[edit] Oh yeah - the other issue is wanting all this native control drawing with transparency where it should be, PLUS still allowing the newer OS's to do all that fancy shmancy animation and fading. So far success 

[Scott]

Hardly worth a new thread IMO, but there was a challenge on another site I frequent to make a game in 2 hours. Well I spent 6, so I didn't pass the challenge. It's a 3d procedural tunnel-of-dots race-against-the-clock. Your speed is directly related to your distance from the tunnel wall, however touching the wall will bounce you back towards the middle, slowing you down. Acceleration is impl. with sideways movements but not forwards and backwards so it's a bit clunky. Also it's my first game ever that works on Windows and linux. All binaries are in same zip here.


As for Stickimator, here's the to-done since last time.

- ADDED - Timeline ripple mode replace gives yes/no/cancel instead of just yes/no
- ADDED - Timeline undo/redo impl. for all actions
- ADDED - Combobox background correctly transparent on windows 7 (it stopped being square!)
- ADDED - Slider controls can disable showing tics (wanted for timeline panel)
- ADDED - Loading support for V2 files (could only load V1, save V2)
- ADDED - Background image path is saved to document if from file and not clipboard
- ADDED - Background source is shown in props
- ADDED - Consistent tooltip text for all sets of controls that might need them
- FIXED - Regression: Couldn't hide skinned bones
- FIXED - Regression: Memory leak if load ske file with skins
- FIXED - Regression: Skin editing completely broken
- FIXED - Background prop window's enabled status fixed when undo/redo a background change
- TWEAKED - Internal overhaul of Gui subsystem. Far more consistent inheritance hierarchy (and about the only thing in the entire project using actual inheritance). Finally has shared tooltip functionality and usage. Almost ready to refactor into a standalone library.

[Scott]

Finally back to work on this.

Fixed the UI shadow algorithm. No more seams at the corners. The top one is the corrected version, the bottom is the old version. Yeah it sounds like a boring update, but it has really crawled up my skin for some time!

[Scott]

I want to get back into making games, so Stickimator was used to help start a simple game. It turns out a very crucial detail was overlooked on my part. There must be a way to trigger events! Things such as:

- A foot hit the ground - do a sound effect, shake the screen or something
- The animation is done 'enough' - Think of a brawler game. When you punch, you don't want to be able to trigger a new action (except taking damage) until the punch animation is a certain amount finished (such as when it is meant to connect). On the other hand, the animation may continue past the "connect" frame in some way if the user didn't input another action, probably while "tweening" back into a stand-and-breath-really-tough-like animation.
 
Stuff like that. On the other, other hand, it would be nice to have an animation graph for what can lead to what after what action .. when .. but that's looking further down the road of potential features.

But we must have events.

It's about ready for an extra early alpha release of what is done thus far. Following that, I shall plan to implement events, frame-by-frame sprite support, multiple texture sources, and more. Also will need to finish help docs and examples. And an example game. Yeah.

[Scott]

Lately
- Been doing a lot of work polishing the texture edit mode (where you define skin(s) in a texture)
- Per-animation speed implemented so an animation can be sped/slowed without having to change the timing of every. single. frame.
- More polishing on timeline editor
- C++ reference library for loading sticki files and producing renderer-independent output

I'd love to make a quick video or something demonstrating the work flow but I lack reasonable looking textures. Once I can get a hold of some, I intend to put something up.

[eyeliner]

YES!

I like the premise of this tool!

[Indie_Joe]

This seems really interesting (and technical!)...I'm one of those programmers who is clueless about art 

Did you decide to create this to help you with your own games?  How goes the game you started using it with?

[Scott]

Did you decide to create this to help you with your own games?  How goes the game you started using it with?

Getting good games out is basically dependent on your tools right? So off I go searching for a good 2d skeletal animation program more than a year ago, and I finally found... nothing! What? Nothing? Must say I was very surprised.

I mean there were a couple - but they were very rough imho. The problem of course is these types of tools take a lot of time, and much more so to get them right. Most people just want to get on with making their game when their tool is "good enough". And understandable so.

So yes it was basically to help me make games that consisted of characters that aren't based on spheres and circles haha. It'd be ever-so-much cooler if one day I even found an artist to work with.
---
Aside from this, I think that many people besides myself could use it. With a good work flow and polished, thought out interface (this part takes so much time), and well-debugged, hopefully less people will spend the weeks or months creating their own "enough-to-get-by" version and use this and get on with their game.

It should make animating things, regardless of your(or my) approach, much smoother, quicker, and enjoyable.

[Scott]

Also, with the reference library that comes with it, it should be fairly easy to just plug it into your renderer and voila your game supports smooth 2d skeletal animation and more.
---
Anyway hopefully the technical details, while accessible, are reasonably abstracted so an artist can feel like they are working with a powerful tool, and a non-artist can still work with it and not feel lost. For instance, the last 2 days have been devoted to handling:
What happens if you are using texture(s) for skinning, and you replace the source image of those textures?

In a game one will have already orchestrated texture-swapping to just work, but the editor can't assume that. What if the image is a different size? Specifically, what if some textures which are currently used as skins don't fit on the new image?

Plus, there is texture(s) auto-detection when you load a new image (based on alpha or color-key). It must integrate well into the replace-texture functionality too.
---
The solution being tested is to analyze all textures (both used and unused) in the image, see if they fit, then present the user with options on what to do. Assuming anything here on the editor's part would be bad. Even if they all fit, just the image being a different size can be a red-flag, so we still ask.

From the user's perspective, they only know something is going on if there is a potential problem, and then they are only asked a quick question with a very small number of sensible choices.
---
Next: Apply the same safety check principles to re-autodetection and to deletion of textures in an image which are currently used as active skins. Make it all transparent and not annoying to use.

[TacoBell_Lord]

This looks very accessible, dig the framework. How is it with Flash/AS3?