Will this be your last SpriteKit project?

The project I'm currently working on will be my last SpriteKit project. With about 14k lines of code I can't afford to switch to another library so I'm stuck for now. I'll never make the same mistake again and rely on this framework though.

I had also started sketching out other projects with SpriteKit but will abandon all of them and rebuild with other tools.

With all the problems SpriteKit has in iOS 9 and Apple's lack of communication about the issue, have you decided to abandon the framework as well?

Replies

No. I've had a few issues with iOS9 but the only thing causing me issues right now is SKLightNodes which aren't useable in gameplay, other than that I'm hitting 60fps across devices I've tested on (iPhone 4S being minimum spec).


I realise not eveyone is in my boat (like yourself), but for me I really like the framework and action system and can get it to do what I want even if iOS9 has been irksome.

Are you doing this as a hobby or professionally (to make a living)? As a hobby I might not mind so much...

Well I am a professional developer for my main income, but not game dev. I work as a self employed indie developer at evenings and weekends writing iOS games. So you're right, my game engine decisions don't directly affect my mortage or feeding my kids! I really like the Swift language (although my profession is actually C#) which is a reason I started game dev a year ago. If I was ever to consider using something else, it would probably be along the lines of Cocos2D (I really really don't want to go with Unity).


But as I said above, yes I've had a few issues with iOS9, but it doesn't seem to have caused anywhere near the problems to me as it has others - I was lucky to avoid the zPosition issue and others were only minimal impact - a lot of that was because I wrote a texture singleton manager when I started my current project, so a lot of my calls go in through common code so only requires fixes in one place.


So yeah...for me....I'm willing to keep on with SpriteKit and hope that internally Apple realise they goofed with SpriteKit and iOS9 and won't let it happen (at least to this extent!) with iOS10.

Lucky you. My project runs nowhere as good as it is on ios8. I have no idea if it is going to change with the next ios releases. And should I wait for 9.2 or 10.0?

I've been using cocos2d-iPhone extensively, and lately cocos2d-x because cocos2d-iPhone seems to be dead more or less, and x ain't that bad. But I have fooled around with SpriteKit and unity too, and while I do like SK more than Unity I have yet to release anything with SK... And just one game with Unity. Unity is a huge waste of time for me... I guess it all boils down to how work is carried out but as the sole programmer in a small company where no one touches anything more technical than Photoshop, having to do Unity game programming as well as platform engineering is just too time consuming. I need the whole team to work almost exclusively within Unity of it wont get productive, at least that's what I feel. This is where open source like cocos2d-family excels. Someone already did and published the work you need to do and it just takes some customizing to get it to do what you want ;-) SK is, like Unity, closed source so you have no idea where it is going, if some bug will ever get fixed or not. You can't even fix it yourself. With Cocos you can. Sure SK and even Unity can have some killer feature here and there. With SK we can easily have video textures, how sweet is that :-) I actually wrote one and the same game with all three above mentioned rendering frameworks half a year ago. I wanted to compare the performance. In the end all three had good enough performances, but I chose cocos2d-x in the end just because of the open source community. And sure there were business reasons beyond me, to allow for other platforms later if we ever needed to (we haven't, just yet though) That said I think SK is pretty easy to work with and I often used it for prototyping ideas. It's kind of fast to get going... Now, any framework would be when you get used to it. To me SpriteBuilder of cocos2d-iPhone was a killer feature, it was so easy to set up scenes in the GUI instead of fighting with pixel positions in code. I don't think x or SK has anything near those GUIs yet. Now I'd love to crank out a game for the new ATV soon, using SK. Ok that was a random rant but I guess my point is getting used to a few differ men rendering engines is not a bad idea, to get some perspective. And I guess there are a bunch of other options out there that I have yet to try. Bottom line for me however will be strong open source community support.

  • @Jbmechanic. I hear you, I was heavily invested In Cocos2d-iphone when it started dying. It was/is an incredible framework that at one point was responsible for a great percentage of the games in the App Store. Unfortunately, the creator left to move onto Cocos2d-X and the subsequent caretakers of the library completely underestimated the importance of backwards compatibility. So when version Cocos2d-iPhone 3.0 came out it disenfranchised almost all the original adopters.

    Interestingly, this happened at. the same time that SpriteBuilder was introduced to try to attract new developer with a basic point and click interface. While there was certainly nothing wrong with that goal, the lack of backward compatibility seemed to Imply that the caretakers had somehow decided that attracting new developers was much more important than keeping the current (invested) developers. So since there was pretty much no path to migrate from version 2.x to 3.0, they completely killed the user base as many developers (myself included) felt justifiably burned and therefore decided to move onto other frameworks. Many went to Cocos2d-x and others went to Swift, and also some to Unity.

    Eventually Cocos2d became Cocos2d-Swift which more or less made no sense because it did not bring that much more to the table than just using Swift... So any new developers that they attracted ended up just going with the pure Swift library solution (which I honestly feel was based upon Cocos2d-iPhone as. it was open source).

    Cocos2d-X still seems to be thriving and has many backers and partners, which is great... but Cocos2d-iPhone/Cocos2d-Swift is now simply gone... no website, no forum, no nothing... it is really sad to see how a library that was so awesome, that has even more untapped potential could be killed so fast by the poor decisions of just a few (probably well intentioned) people.

Add a Comment

hhim this forum is weird. I access it from my iPhone 6 Plus but there is no way to edit posts(?) I had a few spelling mistakes up there. Can't fix, doh!

There's the "Actions" button. When you tap it there's an option to edit a post.

The manner in which Apple has (mis)managed Sprite Kit has lead me to consider Open Source.


I'm from a design background, I'm used to products working, and rapid, informed updates and notifications about any and all problems.


I now see why developers value Open Source game engines and frameworks.


The potential and promise of Sprite Kit and Scene Kit is what drew me in. I believed their pitches at WWDC. Silly me.


Scene Kit (and now Model I/O and Game Controllers and Replay Kit and GamePlay Kit) has lead me to question the validity of ever locking into anything Apple does. that's closed and subject to their (incredibly) slow and silent udpate process.


It is a great shame that this company that claims to be considerate of users is anything but that for their most intimate users, the developers.

Not knowing is a big part of the problem here. And I have zero confidence that this won't happen again with 10.0.

Thanks for your input, cocos2d sounds worth exploring. Other people have recommended it to me as well.

I've reached the same conclusion you have. And in some ways it reminds of Apple's decision to not allow Flash on iOS devices. They had no control over that technology and would be at Adobe's mercy. Well by using SpriteKit I'm at the mercy of Apple and it isn't working out so well!


I'll agree, SpriteKit has a lot of potential and it is pretty easy to work with (when it works). But it is no where near polished enough to consider for serious development and I fell for that one too.

Yes.


SpriteKit on IOS 8 was great!


SpriteKit on IOS 9 was one of the worst product releases from a major vendor I've ever seen.


It looks like 9.2 beta has fixed most of my problems, but the fact that they happily shipped a product with glaring faults tells me that something is fundamentally broken and that it may happen again.


In-conjunction, Apple's communication to developers is horrendous - whilst the the individual tech's are great. The corporate policy of treating developers like mushrooms is not one I'm prepared to live with again. There has been no recognition or apology that "valued developers" have had a rough ride.


My vicious, spiteful ex makes more effort to communicate.


I've canned my Spritekit products and am most of the way through moving to Unity. Sure, I am having some difficulty but the community is helping my team through them.


Never again will I allow my business to be reliant upon the SpriteKit product and engineering team.

Curious why you don't want to use Unity, what are some reasons to avoid it?

All valid points, good luck!

Unity has performance problems that can seemingly never be fixed. I've used it for prototyping for 4 years. For that it is wonderful, easy.


The step from prototype to production quality with Unity means either one of two paths:


1. Massively scale back expectations and work within its stringent, troubling and many, many problems. Find another problem? Compromise the design around the problem. Repeat.


or...


2. Fighting with Unity, which will never end, and will result in grey hair and anguish. Much like fighting with Sprite Kit or Scene Kit, but actually worse.


Aside from this it's huge, slow and clunky. And has been forever, despite forever promising to optimise it.


Part of the attraction to Sprite Kit and Scene Kit (for me) was lightness and inherent speed, both in general, and in terms of iterative testing and development. Building with Unity is a drinks break.