Spine: 2D skeletal animation

Excellent looks great, now I just need an artist :smiley:

I will play around with it later and report if I find any bugs or anything.

Keep up the good work!

Welcome to JGO, Shiu! Wait, how did you get past registration?! Zing! :stuck_out_tongue:

I think pricing for a niche product is hard. With a reduced market size the price needs to be a little high, but exactly where to set it is tricky. What do you guys think would be a reasonable price?

Some similar apps tend to have multiple pricing levels, eg $X for a “standard” version and $Y for a “professional” version. I’m not a big fan of making useful features only available at a higher price point, though I guess it might make sense for certain features (but probably not for Spine).

Some apps say if you make $N/year you need to buy the professional version. This is a way to tax successful apps while keeping the app affordable for everyone else. It is hard to enforce though and I have a feeling doesn’t have much of an impact on revenue.

Some apps have you buy a specific version and offer subsequent versions at an upgrade price, or allow upgrades for a limited time (such as 1 year). This is a way to milk more money out of your user base later. They usually then offer a “lifetime” price which is slightly higher than what they probably should charge.

For some context: Spriter is $25 for preorder. TexturePackerPro is $30 (it just packs textures… which libgdx does for free!). Objecty is $25 w/ updates for 1 year, $96 for lifetime updates, $160 for 5 licenses w/ lifetime updates. Game Maker is $40. Games Factory is $59. UDK is $99 + royalties. Multimedia Fusion is $119. iTorque2D is $149. Corona SDK is $199/year. Unity is $400 per mobile platform.

This would be game library specific. We aren’t planning it for libgdx though. The only decent library to do it is AGG. I’ve done it and it is neat but a huge pain (see PennyPop).

Well, we tend to only tackle projects where we have ideas for innovation. Physics is hard.

Uhg, not sure why this happens. Spine watches the filesystem for changes to the image directories. Adding/removing files from your image directory will add/remove them from Spine’s tree instantly. Also, editing an image on disk will instantly update it in Spine. We use JNotify for this. It is supposed to use INotify on Linux but it appears to fail here. The path is right. I’ve tried using an absolute path, same error. Not sure where to go from here? :frowning: I could add a refresh button to the tree for Linux, but it’s unfortunate to lose this cool feature.

Could someone test the filesystem watching on Mac? On the filesystem delete an image, add an image, and edit an image used on a skeleton.

Although I am always a fan of free

I’d personally say
minimum $20 (no question, do not go lower than this)

$40 maybe?
----- (with free upgrades for 12 months after purchase date)

-----($20 for pre-orders?)
---- (preorder costs same as $40, but offers lifetime or 2-3 year free upgrades)

no more than $100 (unless you plan to have some very unique/special features)(idiot proof, tons of documentations and help with at least 2-3 different game libraries/framework)

Although I haven’t personally used it yet, and I am not sure what sort of additional functionality it has yet, so this is just from having used the other tools you mentioned and looking at the videos.

No royalties.
(perhaps $40 for ‘spine mentioned in credits’, $80 for no credit needed)? Although impossible to enforce

Do you think there is enough stuff to be continued support to justify a ‘subscription’

Lastly, you could always go the
‘yay indie’ approach.
the normal price, 30-40, 80 or whatever for most people, unless you are a ‘bigger company’ or an ‘indie studio’ producing profits of excess in $100,000 annually, then charge them $250 or something. Although this is once again ‘trust system’

Very impressive. Great work

I implemented the same thing for my framework, and I used the standard feature from Java 7. And it just works everywhere.

Except Java 6. :wink: Thanks for the tip, I haven’t looked at that new stuff much. I think that is the way I’ll end up going. Under Java 7 can have a refresh button.

[quote]Welcome to JGO, Shiu! Wait, how did you get past registration?! Zing! :stuck_out_tongue:
[/quote]
I cheated and had ariel tell me what the result was, pasting stuff in eclipse is beyond me, you know that.

Shiu and Ariel, I am disappoint. :frowning:

Oh my FSM this is amazing! It’s just so smooth and slick and pretty already. Really great job so far guys…now if you could someone program a human to be my artist… :stuck_out_tongue:

Errrr…you do know LWJGL has a hidden switch that allows you to remove the decorations/chrome right? No need to go through clunky old AWT. Just call before initializing the Display:


System.setProperty("org.lwjgl.opengl.Window.undecorated","true");

Bah, no, I didn’t know that! However LWJGL can’t get/set the minimized or maximized window state so I’d still have to use Swing.

Ah yeah that’s supposed to be planned for LWJGL 3.0 :-X

Worked here on windows 7 java 7. Took a long time to load but that might be my computer’s fault.

It’s a very nice UI. Does it use com.badlogic.gdx.scenes.scene2d.ui or the Themable Widget Library (TWL)?

With regards to pricing, I think that charging more for big studios and for super-successful games is very reasonable. They could easily afford to pay 500 or $1000, and maybe for that price they could also get the source code which would help them tweak/integrate it into their build chain.

The way it exports the data will be interesting. You mentioned something about JSON data, but for noobs making basic java2d games, ideally it would dump out java code with lots of AffineTransform operations in between Graphics2D.drawImage calls which could easily be cut and pasted into their programs.

Well, you do deserve a lot of credit(s) for this, but I think over $70 a pop is overkill. With the framework for this kind of program, you can easily make a few more like it, doing different neat things, and sell each for $35-70. It is correct that it’ll almost be impossible to enforce any “if you sell more than X copies” or “mention us in the credits” limitations, but I know I would gladly mention you guys in the credits even if I pay to use the program :slight_smile:

The thing is, no matter what kind of protection you choose, someone will crack it anyway. You know this. So there’s really no need to complicate those matters for paying users. What they get, is not having to wait for pirates to crack each update (unless they can crack that bit too). Most developers will gladly pay for just that. But then, you sound like you’re almost done anyways. So what would they need updates for…?

Sorry, I’m rambling. Bottom line: I’d happily pay around $40-45.

He mentioned that he uses scene2d.ui :wink:

Nope I don’t think they should target Java2D at all.

Sooooomebody didn’t read the wall of text! :smiley: scene2d.ui FTW!

[quote]With regards to pricing, I think that charging more for big studios and for super-successful games is very reasonable. They could easily afford to pay 500 or $1000, and maybe for that price they could also get the source code which would help them tweak/integrate it into their build chain.
[/quote]
We wouldn’t give out the editor’s source code. The runtime code that you use in your game will be available though. Doing that reduces support needs a little, so I’m not sure if it would be good for users to need to pay more to get the source.

[quote]The way it exports the data will be interesting. You mentioned something about JSON data, but for noobs making basic java2d games, ideally it would dump out java code with lots of AffineTransform operations in between Graphics2D.drawImage calls which could easily be cut and pasted into their programs.
[/quote]
Honestly I have a hard time taking Java2D games seriously. Don’t get me wrong, cool stuff can be done there, but I feel like using a gaming oriented API (like say, libgdx ;)) is both easier and has greater potential for games.

The plan is to have a runtime library for each of many gaming libraries. This is already done for libgdx, as the editor uses the same code that would be used in a libgdx game. I will then port that to other libraries like Unity, cocos2d, etc. I’m not looking forward to that. :wink: Java2D could be a target, but it is low on the list. The data will be available as JSON so you could write your own runtime stuff, but it is not trivial to get it right. It’s only about 1200 LOC for libgdx, including reading JSON and binary, but there are some quite tricky lines. :wink: FWIW, the editor is ~15k LOC (using the CLOC tool, unscaled numbers). This doesn’t include scene2d or libgdx of course, which is something like 150k LOC in total.

:o Great, now I’ve spit my beverage all over my monitor. :stuck_out_tongue: I don’t see what other programs are similar enough that a large portion of Spine could be reused. Sure, any GUI app could be built with scene2d, but Spine has taken an enormous amount of effort to solve the problems it needs to solve in a user friendly and polished manner. It has been about 4 months of work full time each for an artist and a coder, pushing it hard. It’d be that all over again for another, different app of the same complexity. For some perspective, let’s call it 8 man months, assume we can make $100k/year at a real job (this is low), and we can estimate Spine has costed ~$70k just to get it into a beta state. In reality it would be more, because there is no way we’d bust our asses like this for an employer. :slight_smile:

[quote]no matter what kind of protection you choose, someone will crack it anyway.
[/quote]
Oh, there’s no need to discuss copyright protection. I’m just interested in what price point would be reasonable for paying users. FWIW, the trial can’t be cracked because the export code is not in it. It can be decompiled and you can write your own export, but that’s a lot of work. The full version could be shared, but those people are lame.

[quote]But then, you sound like you’re almost done anyways. So what would they need updates for…?
[/quote]
Ha! You’re killing me here. :wink: There is a very, very long list of features we’d love to see. It has been a struggle so far to reduce scope and not try to do too much, else we’d never finish. The biggest piece that is missing right now is the runtime for various game libraries.

[quote]Bottom line: I’d happily pay around $40-45.
[/quote]
Noted, thanks. :slight_smile: Does anyone else think a ~$50 price point is about right? (see what I did there, bumping it up by $5 :P)

Yeah, well, when you put it like that. I hope you didn’t feel like I was putting you guys down or anything. I was just trying to raise some realistic points to consider.

And all I meant was, the general setup and smooth design is not something you should have to do again for something similar. I could think of a bunch of little programs that need a GUI just like that one; drawing and connecting lines, the touchpad-interface with the waveform and such. With your imagination and skill, you could make a fortune.

And well, it just sounded like the runtimes were the last things on your list. It seems almost complete for what it is.

I saw what you did! Get paid, bro :stuck_out_tongue:

Haha, no worries, our Internet feelings aren’t hurt so easily. :slight_smile: I just think it takes quite a bit for a tool to be useful enough that someone would want to buy it. It also has to be a hard enough problem that others haven’t solved it (very well). Even then there is a chance someone will put up some OSS to obsolete the commercial tool.

Eg, TexturePackerPro is a GUI tool that packs sprites and Andreas has done pretty well selling it. I wrote a (sweet) texture packer in libgdx just because I wanted a command line tool with specific features. Aurelien wrote a GUI for it and now there is a free alternative to TexturePackerPro. Aurelien also wrote a “physics editor” as a free alternative to Andreas’ commercial physics editor tool. I don’t know if Aurelien has it out for the guy or what, but if people are going to buy a tool it needs to bring something pretty serious to the table.

Java 7’s WatchService doesn’t watch subdirectories. Windows has native support for this, Linux doesn’t, so we get the LCD. JNotify handled it for you (well was supposed to, had it worked on Linux). Oh well, I’ll just add a bunch of watches and call it a day! Nice part is the download size will drop since I don’t need so many natives.

The links in the first post have been updated to 0.81beta. The filesystem notification has been rewritten using Java 7, though the app will still run on Java 6 (though with no automatic image updating). I tested on Windows and Linux, but should work on Mac. :smiley:

Nice work you two!

@Nate: OSX works fine for the whole CRUD gamut. Glad you mentioned Java 7, because it wasn’t loading changes until I switched it to 7 :wink:

Hello,

I tried it on a windows XP 32 machine, the graphics card is a nvidia NVS 300.
I first have an error in a popup :

Spine-0.8beta.exe - Unable To Locate Component

This application has failed to start because MSVCR100.dll was not found. Re-installing the application may fix this problem. 

Then in the spine.log I have this :

Spine 0.8 BETA
Uncaught
com.badlogic.gdx.utils.GdxRuntimeException: com.badlogic.gdx.utils.GdxRuntimeException: OpenGL is not supported by the video driver.
	at com.badlogic.gdx.backends.lwjgl.LwjglCanvas.create(LwjglCanvas.java:175)
	at com.badlogic.gdx.backends.lwjgl.LwjglCanvas$1$1.run(LwjglCanvas.java:71)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$200(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: com.badlogic.gdx.utils.GdxRuntimeException: OpenGL is not supported by the video driver.
	at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.createDisplayPixelFormat(LwjglGraphics.java:221)
	at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.setupDisplay(LwjglGraphics.java:181)
	at com.badlogic.gdx.backends.lwjgl.LwjglCanvas.create(LwjglCanvas.java:167)
	... 15 more
Caused by: org.lwjgl.LWJGLException: Pixel format not accelerated
	at org.lwjgl.opengl.WindowsPeerInfo.nChoosePixelFormat(Native Method)
	at org.lwjgl.opengl.WindowsPeerInfo.choosePixelFormat(WindowsPeerInfo.java:52)
	at org.lwjgl.opengl.WindowsDisplay.createWindow(WindowsDisplay.java:229)
	at org.lwjgl.opengl.Display.createWindow(Display.java:303)
	at org.lwjgl.opengl.Display.create(Display.java:845)
	at org.lwjgl.opengl.Display.create(Display.java:754)
	at com.badlogic.gdx.backends.lwjgl.LwjglGraphics.createDisplayPixelFormat(LwjglGraphics.java:209)
	... 17 more

Other LWJGL applications work correctly on this computer ( like my game … ), so I don’t know what’s wrong here.
For info I have 2 monitors. The java version is 1.6.0_26.

Otherwise I also tried it on a win7 64 machine, and everything worked fine. The ui is really amazing … to the point that I’m thinking very seriously to use scene2d.ui instead of SWT for the UI of my map editor. Already tried to integrate some widgets on top of my map display and it worked great :slight_smile: