New video documentation on Objects for the Fantastic Worlds iOS Starter Kit

Here’s a new video for the Fantastic Worlds iOS Starter Kit.

In this video, will talk about common and not-so-common Objects, which is an intentionally broad word, since Objects could be anything from background art, walls, platforms, tables to push around, and increasing in complexity to falling boulders that damage the character, laser beam guns, roaming enemies, monsters that throw projectiles or simple friendly villagers that impart clues.

New features in Build 1.0.2 of the Fantastic Worlds iOS Starter Kit

I suppose I should start posting new entries to the documentations for the Fantastic Worlds iOS Starter Kit right here on the blog. The documentation has all these same properties already noted, so you can follow the link(s) to the documentation in the previous link, or go here to download the iBooks file or PDF file directly.

New in Build 1.0.2

For Levels

  • ReverseGravityThisOften – A decimal value for how often (in seconds) the level will reverse (or change) gravity using the value below.
  • GravityReverse – (for Levels)This is a vector defining the x and y direction that gravity will switch to using the property above.  For example, a value of { 0, 1 } would pull the character up some, if the regular gravity was normally { 0, -2 } . This example could be used to make a side scrolling level appear to have a watery effect to moving through it.

For Objects

  • GainHowMuchHealthEverySecond – a decimal value for the amount of health an object will recover every second. This could be useful for “boss” characters that are meant to be more challenging to kill.
  • ParallaxOffset – An offset value in {x, y} format for the amount to shift the object when the character moves (or when the world is moved essentially). You can create parallax scrolling effects on either the x or y axis (or both) using these amounts. They can be positive or negative decimal values. For subtle effects, use small decimal values. When experimenting with parallax scrolling, I would recommend leaving either the x or y at 0 to see how the effect works on just one axis first.  For side-scrolling levels, this would mean leaving the y value at 0.
  • DontDestroyWeaponsOnContact  – A YES or NO value that prevents weapons (thrown by a player) from being destroyed on contact.  For example, you might want a rock (thrown as a weapon) to simply affect the physics of this object, if so, set this property to YES. By default, this value is NO, so any player-fired weapon breaks against it.

For Buttons

  • DoesWhat with a value of UseWeaponAndAttack will do exactly what tapping the screen does (if tapping to attack is not disable). This makes the character use their attack animation frames, and use a weapon (fire a projectile). So for example, the character might fire a gun, and the animation would show a little kick-back from the gun.   (sorry this should have been in Build 1.0 for anyone using a virtual D-pad).

For Weapons

  • FiringParticleFileName –  This optional property is the name of the .sks file to show when the weapon is fired. Like all uses of Sprite Kit Particle files, you do not need to enter .sks into the value. So if you plan to use a file named GunFire.sks the value to enter here is just GunFire.  This particle effect will move along with the projectile.
  • NumberOfFiringParticlesToEmit – An integer value for the number of particles to emit.
  • FiringParticleXOffset – An offset number value on the x axis for where the particles will initially appear. This value is multiplied by -1, if the character is facing left.
  • FiringParticleYOffset – An offset number value on the y axis for where the particles will initially appear. This value is multiplied by -1, if the character is facing up.
  • FiringParticleDepth – The depth the properties appear at. Use -1 or any number lower to make the particles appear behind the image of the weapon. Use 1 or any number higher to make the particles appear above the weapon.

For buyers, to update your kit from 1.0.1, simply copy and replace the… Version_Notes.rtf,  CSWeapon.m, CSLevel.m, CSObject.h, CSObject.m, CSInventory.m, CSButton.m, constants.h . You’ll be emailed new versions shortly.

 

Video documentation for the Fantastic Worlds iOS Starter Kit.

Last week we launched the Fantastic Worlds iOS Starter Kit (with epic-length subtitle) For Side-Scroller, Top-Down or Isometric Role Playing Games (told you it was long). And now comes the onslaught of video documentation. I’m not one for brevity in these videos, so if you enjoy my voice and over-explanations of nearly everything, have at it (more are coming this week too)…

Fantastic Worlds on Vimeo

Fantastic Worlds on Udemy (with Discussions Board)

And if you want something a bit shorter, check out the playback demonstrations of the kit…

Playback Demos on Vimeo

These show the kit running in a side scroller view, top down view (your more classic RPG style) and the Kids App demo even has an isometric view. And if you just want a quick 2 minute introduction, the video below shows some minimized versions of the playback, along with the iBook documentation, and a little hint of how Tiled and the Property List function together.

 

iBook Documentation for CartoonSmart’s Fantastic Worlds iOS Starter Kit with Sprite Kit and Tiled

 

Fantastic Worlds iOS Starter Kit for Side Scroller, Top Down or Isometric RPG Games
The documentation for CartoonSmart’s latest (and greatest) iOS Starter Kit is officially ready! Download all 170 pages in glorious iBook format (for free) right here….

Fantastic Worlds iBook Documentation  (viewable on your Mac or iPad through iBooks)

Or the slightly less glorious PDF version…

Fantastic Worlds PDF Documentation (viewable anywhere)

The Fantastic Worlds iOS Starter Kit is also for sale too, but I’ll do a separate article about that shortly.

 

 

 

 

 

Documenting my latest iOS Starter Kit (Yup, Sprite Kit based)

Sorry for the long silence folks, I’ve been deeply immersed in building a Sprite Kit Starter Kit. I think a lot of you can guess the general theme  based on the screenshot below, but what the kit turned out creating was even better and bigger than what I originally intended or imagined. So I’ll leave a little mystery until it’s ready. The kit is ready, but I have to document it. And in royal fashion, its getting the same iBook treatment that my StoryTeller’s Starter Kit got. Since it is entirely Property-List driven, every property needs an entry and that is hundreds upon hundreds of entries.  And since I tend to WAY over-do things, the documentation / guide even has tips on using Xcode for the first time.

Anyway, expect some fun things to announce very soon! I’ve been at this project for months now, so I’m getting excited myself. But it must be perfect =)

Screen Shot 2014-04-14 at 5.09.16 PM

Update on Role Playing Games with Sprite Kit Part 2

Ahoy-hoy students!

For those of you that enrolled in my first Role Playing Games with Sprite Kit course, here’s how part 2 is progressing. I’m almost to the point of recording the lessons. It took me way longer than I wanted to get to this point because I kept adding, and adding, and adding more and more to this second set of lessons. And fortunately the original setup (what you have at the end of the first part) plays nice with the future parts to come.

So what will change from part 1? Levels are totally non-linear now. In this first set of lessons, we stepped through levels in order, like level 1, then level 2, etc. And we did so by collecting coins. Coin collection was a quick way to advance levels but as I pointed out to everyone who took the course, this was never the end-goal for navigating the world. Role playing games are more about the mystery of discovering items or clues that help you find your way, then they are about simply gathering up money in a mad dash.

Levels can be huge landscape areas or tiny rooms. You’ll typically have a portal to enter (a door, cave, whatever) and a similar portal to exit. So obviously we’ve got a Portals class in the next set of lessons as well.  The game will now have Save Points, so you can choose which levels are deemed worth starting back from. So if the player makes it out of a giant maze, thats probably a good save point.  You can use portals to jump around within the same level or to another level. Portals can be locked and unlocked, and you can optionally create “trick” portals, where if you don’t have a certain item, you would end up someplace you don’t want to be when colliding with the portal. Imagine a hole in the floor type situation. If you the player hasn’t collected the plank item, they would fall through the hole.

Inventory has been added. In fact, I think a good start to this next set of lessons is to program the inventory class. We’ll make the inventory all saved in the NSUserDefaults, so if the user decides to quit the game and play again a month later, their inventory is still there. And what exactly is collectible? Well anything really. RPG’s usually have keys that unlock doors, so that option has been added. You can have portals to other levels that open up once a certain item or number of items has been collected. Inventory can be attained by simply colliding with the item (like the player collided with Coins in the first lessons), and I’ve also added the option to have items collected after attacking an Object (class) or by colliding with the Object.

Objects. We’ve got an Object class in this next series of lessons which can be used for A LOT.  You can collide with objects (push them around using physics properties), objects can damage you (for example a torch might harm you), objects can be animated, they can move back and forth / or up and down, and you can even read pop-up images if you collide with them. So an object could be a person in the game that delivers you a message when you bump into them. Or they could be a little gremlin that roams around to cause you damage. Objects can also  And again, you can attack objects and have them break with an optional particle sequence and optionally leave behind a collectible object.

Map Class / Start Screen. We’ll add a map so the user can choose where to begin the game (from levels they have already gone through). So the game can begin with either the map or just jump them right into the last-played level.

Invisible Boundaries.  While objects can be used as collide-able boundaries, thats not always going to be the option to defined where the characters can go. So we’ve not got a Boundary and Edge class to really fine tune the playable area. The Boundary class will create either circular or square areas that the character can’t enter, and the Edge class can define lines ( better for diagonal areas)

Tiled Backgrounds. Yup, we’ve got some tiled backgrounds with Sprite Kit. So if you wanted to create a path through a level, you could use a single square image, maybe 100 wide by 100 tall,  then tile it so the path repeats over an area that is 200 wide by 800 tall.  Or you could just tile the entire area of the level you want playable, for example, just a bunch of grass tiles. You can also adjust the size of the tiles within the playlist.

Sounds: We’re finally adding sounds!

What Else?  There’s more, but I think this covers most of it. By the end of this next series, you should have a greater understanding of Sprite Kit, and a very playable game.

 

A Brand New Zombie Air Strike and Why There’s No Shame in Mediocrity.

My latest app, Zombie Air Strike 2 was released this week! It combines Sprite Kit, good ol’ fashioned UIViews and a lot of gorgeous satellite map data to explode zombies (or really radar dots so you can pretend those red dots are anyone you want.).  Its free too for both the iPad or iPhone. Tap the image below to visit the App Store or keep reading for some history on the app…

Zombie Air Strike 2


This latest app is a sequel to my first Zombie Air Strike game which, despite “meh” early sales, turned out to be a solid seller for me in the long run. What’s solid? Maybe at best $350 a month. But considering after the initial development time, I only did one upgrade (for the first Retina device, thats how old it is), and let it just sit in the store. Now thats not that greatest way to build a fan base for an app, I should have made some significant upgrades over time, and you could argue Zombie Air Strike 2 should have just been an upgrade to the past version, but the point is, it more than paid for itself in the long run. 

The long term livelihood of an app is sometimes hard to fathom after spending months developing it, even if its just time you spent in the evenings or your free time. Its never fun seeing low download numbers and single-digit In-App purchase numbers. And thats when I think a lot of developers second guess their work.   They do things like run ads overtop their masterpieces to try to recoup some of what’s seen as “lost money due to lost time”. Or worse try to sell the source code or the entire app to sites like Apptopia. Nothing against that site, I think its fine to sell your app if that was your goal all along, but not out of frustration and try to make a quick buck as an exit strategy. 

You’ll never know what can happen organically with your app in a year or even two. Long after the first Zombie Air Strike was even something I checked stats on (and I didn’t regularly because it was under a personal account, not CartoonSmart’s), I met a fireman at a party (that sounds funny) that told me he and all his co-workers were into this game called Zombie Air Strike. I hadn’t told him I was the developer, we were just talking about iPhone games. That showed me there was probably more potential in that app that I gave it credit for. What if I had added 10 new cities a month to it? Or expanded the gameplay? Obviously word of mouth had gotten me a firehouse full of sales, so if I had fostered that audience more, what else could have happened.

Think about how many bands got together in 2003, and you just heard their first big single in 2013. So give it time, my fellow devs. Let your app breathe a little. And if there’s a sub-point to this article, consider revisiting old ideas. Thats obviously what I did with Zombie Air Strike 2. I liked the concept of using real map imagery in a game, and I wanted to share that. Something you thought about doing 4 years ago, might not have been possible until iOS7. And of course (shameless plug coming…) , you know CartoonSmart has tutorials for iOS development.

Zombie Air Strike 2