Mike at BrashMonkey

Upon re-reading this post of mine, please keep in mind I'm not talking specifically about you or directly to you..as I've seen and tried to help several artists who fell into this trap early on.. and when this topic comes up I tend to cover all the points and flavors of every incident with each of the specific artists.  So please know I'm not trying to pin any psychological or philosophical position onto you... just trying to cover all the bases for any other artist as well who might stumble upon this forum thread when facing the same issue/decision.
 
____________________________________________________________________________________________________________
 
 
Hi again Symbolic.
 
To use fantastically appropriate word-play, no matter how you cut it, creating the level as one giant illustration is just a bad idea.
 
1) Super hard and time consuming to drastically edit a levels design after you've already created it, which is in the vast majority of games, especially side scrolling games, critical for ensuring fun gameplay!
 
2) Super wasteful of the platform's texture space...no matter how small you cut up a giant painting, its still ALL THERE... Imagine you cut it into 4096x4096 textures...you're still going to have at least two of these taking up texture space at a time at all times...and even this size is far bigger than ideal for optimal
performance.
 
3) Super wasteful of the games file-size, download size.
 
In short, using giant bitmaps for levels (even cut into pieces after the fact then reassembled in the game engine) is nothing but an inexperienced game maker trying to make something work within their current experience and tool-set comfort level.  This is an age old problem..people bending over backwards to try to rationalize and execute a very un-optimal solution to a situation using whatever limited knowledge base and tool set they currently have.  It typically leads to either disaster or a drastically inferior final product taking drastically longer to make, causing immense stress, frustration and exhaustion for the artist and delaying or dooming the entire project.
 
 
Please consider that taking a few days to research a more optimal option will empower you for the rest of your life, (all future game projects) and will end up saving you a ton of time and energy over the remaining course of this project, and for every future game project for the rest of you life. It's THAT important.
 
Important points I want to make:
 
1) Please DO use illustrator, but NOT to create entire levels, only to design the segments you will use to create the entire level in a proper level editor.
 
2) Please always do your research as thoroughly as possible when confronted with any new MAJOR task.  Creating many large levels for  a game is a HUGE undertaking, and it's critical you "power up" before you dive in blind and shoot yourself and the entire project in the foot with an "I'll wing it" approach.
 
3) An unwillingness to learn and add new tools for the right job to your tool belt will lead to  drastically more depressing and unsuccessful life.
 
did you click the link I provided to those resources for 2d level editing in Unity? The Smart-Sprite functionality is definitely one of the things you should learn and strongly consider using. Rayman Legends is an absolutely gorgeous game who's levels often look very much like giant hand painted masterpieces, but its all smart-sprites and re-used hand placed scaled and rotated segments.
 
Here's a peak into what a truly great 2d level editor looks like: https://youtu.be/y-chi097uV4?t=7m7s
 
As you can see, its a more advanced version to smart-sprites but extremely similar.
 
I assume you wouldn't draw every blade of grass from scratch no matter what... so instead of making a group of grass blades and stamping them around in Illustrator, please make your group of grass and stamp it around in a level editor, so its actually a small image being reused in an optimized manner in the game.
 
Lecture now over. Thanks for your patience. :)
 
Cheers,
Mike

Hi SymboliC,
 
I say this with absolute respect and in an attempt to protect your time, energy, and sanity.  This is a common and terrible beginners mistake/misconception.  Levels should be bade out of small, reusable segments (which you can create with anything you'd like)...otherwise you'll cripple the games performance, take much longer to create each level or heaven forbid change a level,  and drastically increase the games overall file-size. Hint, if the graphics program is limiting a max size, its for a reason.
 
I just recently had to talk a beginner game artist friend of mine (who was trying the same thing with Photoshop) down off of that same ledge. Photoshop was slowing to a crawl on his system, but he expected a game, with lots more additional art (animations), a ton of math, collision detection, game logic etc to not crawl while displaying the same image?  Yes, you can chop up the full level to more manageable chunks (for game performance), but level editing and reediting is still just as big an issue or bigger, because the chopping up and putting back together in game is now another step.
 
Ironically, my friend, who was resistant to reusing art then showed me his finished giant hand painted level, and there was tons of reuse anyway.
 
Please look into level editors and tile map editors that work well with Unity ASAP. A Game level can look 100 percent hand painted and still be made out of carefully crafted and reused (with scaling, flipping and rotation..and even color tinting) small segments.
 
PS, Rayman Legends uses the same system of tiling art and reusing small chunks of earth, grass, platform, etc etc.
 
I hope this comes across as helpful and not annoying or pushy.. I've just seen fellow artists exhaust themselves due to this very "idea", only to end up having to redo all the levels they made later, the right way...because not only did it prove to take far too long (especially because there will ALWAYS be constant needs to redesign levels) but because the games performance became absolutely terrible.
 
So, my two cents as an over decade long professional game artist... measure twice, cut once.. do your research and force the programmer to do very realistic benchmarks to make sure you're not making a game in a manner that will destroy itself. I highly recommend you research all your level creation options for Unity.

Again, my alarmist arm waving and hyperbole comes from a strong desire to protect a fellow artist from something that will cause much pain and exhaustion (and typically depression)....This very thing has destroyed countless game projects in their tracks.
 
Sorry if this comes off as abrasive.
 
cheers,
Mike.... but speaking as a pro game artist, NOT as a representative of BrashMonkey in this case.

Hi everyone,
 
Here are a handful of example Spriter files specifically with some metadata set up in the animations for those working on implementations who want to include support for the metadata.
 
1) Variables: This scml uses a string type Variable in the main metadata to keep track of the current letter that's being displayed by the robot.
 
https://www.dropbox.com/s/65vow8a63efaiee/Variable.zip?dl=0
 
 
2) BoxTagVariable: This scml Includes the following important metadata related things:
The Slide animation uses a numeric(float) based variable in the main metadata which could be used to control the x-velocity of the character in the game engine. Ideally, the value would tween between key-frames which have a different value set for the x-velocity variable.  
The Punch has a Collision box called "AttackBox" which itself has a numeric value set up in its private metadata to keep track of the current damage the hitbox should inflict on enemies. The value should tween between keyframes.  
The Punch animation also includes a tag in the main metadata which is used as "state machine data" to tell the game engine whether or not the character is currently "stuck in a move" (can not respond to player input) or not. https://www.dropbox.com/s/es3e406n6qkg7n9/BoxTagVariable.zip?dl=0
 
 
3) PointsTriggers: This Spriter file has the following metadata examples:

1) Both the "throw_knife" and the "throw_axe" animations have action points that appear at the apropriate part of the animation, which should give the game engine the spawning location and angle at which to create the projectile sprites.

2) Both of the animations also include triggers ("ThrowKnife" and "ThrowAxe") at the same moment the action points appear to tell the game engine to spawn the projectiles at that exact moment.
 
https://www.dropbox.com/s/j1x423529nbl0mq/PointsTriggers.zip?dl=0
 
cheers,
Mike at BrashMonkey

NOTE: This humble bundle sale has ended.
 
Hi Everyone,
 
Make sure you take a look at the current Humble Bundle, especially what you get for 12 dollars or more ;)
 
https://www.humblebundle.com/
 
Cheers,
Mike at BrashMonkey

NOTE: This humble bundle sale has ended.
 
Hi Everyone,
 
Make sure you take a look at the current Humble Bundle, especially what you get for 12 dollars or more ;)
 
https://www.humblebundle.com/
 
Cheers,
Mike at BrashMonkey

It's specifically and solely the Steam version of Spriter Pro. But its fully featured and would work well with C2, Only if you have Steam installed and a Steam account though.
 
Cheers,
Mike at BrashMonkey

Hi Jonjon,
 
We agree about Spriter support in general being the top priority, and as RunnerPack mentioned, this has been our focus for the past several months. Instead on focusing on Spriter support  for any specific authoring system (and showing "unfair" favoritism ), our first logical step is a fully featured "generic" Spriter implementation which is as powerful and flexible as possible, and also being carefully constructed so the addition of known future features will be as painless as possible, without the need of drastic re-writes and re-porting the implementation once the new features are added. This is indeed taking longer than we would like, but we're working on it as diligently as possible and apologize humbly for the long wait. I also completely sympathize with your frustration and patience wearing thin.
 
As for Spriter2Unity specifically, reporting the errors you're facing as clearly as possible in the appropriate thread, and to the attention of the actual developers would likely be much more fruitful.  I suggest you first, make sure you're using the latest of everything (Spriter, Spriter2Unity, and Unity). Then get your error list, and report everything as clearly as possible. It's also very important to know that Spriter2Unity does not yet support several of the more advanced Spriter features, so learning what it does not support and learning to at least for now create your animation while avoiding the unsupported features will allow you to work without issues.

Starting a thread specifically to list the known unsupported features would be useful to everyone and might even help encourage current and future developers to get those features supported all the sooner.

That all aside, once our generic reference implementation is finished, our next focus will be on helping with specific implementations, and the order in which we'll be able to help ensure full support for any particular authoring system will depend predominantly on two factors: a) the level of collaboration from the developers/community of each given authoring system and    b ) The general popularity of that particular authoring system.
 
Long story short, Edgar is focusing his full time and attention (as much as possible) to creating the best, most flexible, thorough, and future proof Spriter implementation which should make porting full Spriter support to any authoring system fast and painless once its finished, and, as soon as it is finished well focus as much of our time and resources as we can to helping to port this new, full implementation to as many authoring systems as possible, including of course Unity, which is both very popular and has a great community who have continually donated their valuable time and expertise to supporting Spriter.
 
Cheers.
-Mike at BrashMonkey

Hi Jonjon,
 
We agree about Spriter support in general being the top priority, and as RunnerPack mentioned, this has been our focus for the past several months. Instead on focusing on Spriter support  for any specific authoring system (and showing "unfair" favoritism ), our first logical step is a fully featured "generic" Spriter implementation which is as powerful and flexible as possible, and also being carefully constructed so the addition of known future features will be as painless as possible, without the need of drastic re-writes and re-porting the implementation once the new features are added. This is indeed taking longer than we would like, but we're working on it as diligently as possible and apologize humbly for the long wait. I also completely sympathize with your frustration and patience wearing thin.
 
As for Spriter2Unity specifically, reporting the errors you're facing as clearly as possible in the appropriate thread, and to the attention of the actual developers would likely be much more fruitful.  I suggest you first, make sure you're using the latest of everything (Spriter, Spriter2Unity, and Unity). Then get your error list, and report everything as clearly as possible. It's also very important to know that Spriter2Unity does not yet support several of the more advanced Spriter features, so learning what it does not support and learning to at least for now create your animation while avoiding the unsupported features will allow you to work without issues.

Starting a thread specifically to list the known unsupported features would be useful to everyone and might even help encourage current and future developers to get those features supported all the sooner.

That all aside, once our generic reference implementation is finished, our next focus will be on helping with specific implementations, and the order in which we'll be able to help ensure full support for any particular authoring system will depend predominantly on two factors: a) the level of collaboration from the developers/community of each given authoring system and    b ) The general popularity of that particular authoring system.
 
Long story short, Edgar is focusing his full time and attention (as much as possible) to creating the best, most flexible, thorough, and future proof Spriter implementation which should make porting full Spriter support to any authoring system fast and painless once its finished, and, as soon as it is finished well focus as much of our time and resources as we can to helping to port this new, full implementation to as many authoring systems as possible, including of course Unity, which is both very popular and has a great community who have continually donated their valuable time and expertise to supporting Spriter.
 
Cheers.
-Mike at BrashMonkey

Right, the problem is there is no actual Spriter plug-in for GameMaker yet.  It should happen fairly shortly after we finish the fully featured reference implementation, but its a big project due to adding flexibility and room for up-coming new features..but you can follow its progress in this thread: http://brashmonkey.com/forum/index.php?/topic/4029-reference-implementation-status-update-6282015/

Cheers.
-Mike at BrashMonkey

hi tekkendp,
Yes, if you set set the playback speed in C2 then the animation will play backwards at the same speed the animation would play if the animation were playing forward. BUT RunnerPack is right. A walking forward animation playing revers does not look proper at all... even if the character was like gizmoduck with a unicycle wheel, the characters lean VS the center of gravity etc is totally different.
 
cheers,
Mike at BrashMonkey

I don't know about playing animations in C2, but from an animation perspective, a properly done walk cycle will look unnatural and wrong if you play it backward (especially if you stop the forward cycle at an arbitrary frame and reverse it). If you really need a reversed walking animation, you're much better off animating it separately (hopefully with a good reference example of what bipedal locomotion in reverse really looks like). That's my two cents' worth on the subject, anyway...
 
If it is possible, it could still be useful for other animations, though.

Amazing, Awesome, Stupendous stuff Dengar! You're a treasure to the Spriter community! :)
 
Cheers,
Mike at BrashMonkey

Would be nice to be able to swap with images from a atlas/spritesheet. Right click "replace selected sprite image" only works on images, not on images within an atlas.

Hi everyone.
Please use this thread to post any suggestions you might have for features.
cheers,
Mike at BrashMonkey

Hi everyone,
Thanks for trying Spriter. I look forward to feature suggestions and bug reports.

Amazing, Awesome, Stupendous stuff Dengar! You're a treasure to the Spriter community! :)
 
Cheers,
Mike at BrashMonkey

Hi everyone,
We're proud to announce the release of our 4th Spriter Animated Art Pack, and the last in our series of Platformer based Art Packs. Our new Run N' Gun Platformer Pack is geared towards anyone interested in creating side-scrolling action or platformer games where the player has a gun-like weapon.

This is our most content-rich Art Pack yet, featuring several variations of a fully animated player character, brandishing either a gun, an arm cannon, or a sword, as well as a large assortment of basic enemies, a couple of boss style enemies, and an assortment of pick-up items and effects to add additional visual goodness to your game.

Here are a few reduced size, reduced color, 24 fps GIF exports of some of the animations available in the Art Pack. But you can preview the full art pack here (There might be a long initial loading time (over 100MB of content), but once the first frame is finished loading, the remainder of the preview should be much faster)

Don't forget, this new Art Pack doesn't just benefit those who purchase it. All who purchase Spriter Pro also receive Essentials versions of all of our Art Packs, and this one is no different. The new Art Pack is actually so content packed, that even its Essentials version nearly doubles the amount of art content that is provided for free to Spriter Pro owners. If you have already purchased Spriter Pro, you will receive an email with a links to all of your Essentials packs including this new one.
You can preview the Essentials version of the Art Pack here.
And speaking of Spriter Pro, don't forget, its official release is November 11th, which means that in just 5 days the Early Adopter Sale ends and Spriter Pro's full price of $59 will go into effect. This is the last chance to take advantage of this greatly discounted price, so tell all your friends and fellow game makers! At this time the prices of all of our first party Art Packs will also be increased.

As always, thanks everyone very much for your support and for your patience as we continue to add more value to Spriter and reach this important milestone. We couldn't have done it without your help.
Cheers, Mike at BrashMonkey

I'd personally use a combination of image swaps and just rotating the image from a sensible default pivot point for the hangy belt bits.
 
Cheers.
 
-Mike at BrashMonkey

Hi everyone,
Thanks for trying Spriter. I look forward to feature suggestions and bug reports.

Hi everyone.
Please use this thread to post any suggestions you might have for features.
cheers,
Mike at BrashMonkey

Hi Everyone,
 
As you might have noticed, we've upgraded to a totally new forums system.  The migration seems to have gone off without a hitch, but there's the possibility that if you posted during the 30 minute window in which we were migrating that your post ended up in the old forums and didn't make it over here. 
 
For anyone with a missing post, for a limited time you can actually access the old forum by going here: http://www.brashmonkey.com/forumOLD and copy the text from your post so you can easily repost it into the new forum.  If this is required I apologize for the inconvenience.
 
 
cheers,
Mike at BrashMonkey

Maybe send your Spriter project to bwwd and he can see if it shows up properly on his end?  Also, you should compare other aspects of your projects, like how big are the images you're using?
 
cheers.
 
-Mike at BrashMonkey

Ah, there was the problem. I viewed the GIF in a browser that refused to play it.. I thought it was a single frame. I was not seeing the frame with the obvious IU popping up into it.
 
Thanks,
Mike at BrashMonkey

Ah, there was the problem. I viewed the GIF in a browser that refused to play it.. I thought it was a single frame. I was not seeing the frame with the obvious IU popping up into it.
 
Thanks,
Mike at BrashMonkey

Hi everyone.
Please use this thread to post any suggestions you might have for features.
cheers,
Mike at BrashMonkey