Xcode Sprite Kit Game Application Primer Tutorial

Xcode Sprite Kit Game Application Primer Tutorial

The Xcode IDE, like many IDEs, holds that special fascination for occasions when you, the user, (or youse, the users (chortle, chortle)) can go “File->New Project”. With a few button presses the user will feel that satisfaction of making the fastest progress they can expect to ever feel progressing on a project, as you can see here with the first of those button presses.

This great feeling is well worth it, as long as users don’t fall into the “post FNP navel gazing” period.

Today, we show how, with the Xcode IDE and those few button presses, with no coding (yet), the user can achieve giant leaps in their Xcode Sprite Kit Game .

IDEs are worth discussing in relation to pros and cons with respect to this:

Pros are …

1. speed of initial progress
2. the clarity you get to do with the design aspects of seeing what you have after the initial non-coding FNP phase
3. the main files you will ever need have been created in the right places with the correct permissions, etcetera
4. any makefiles required will have been created and any additional files added will be handled by the IDE as far as keeping the (underlying) makefile up to date
5. there is online help with IDE procedures and search engines are good with your IDE keyword
6. multi-device scenarios catered for
7. debugging facilities are great

Cons might be (my argument is that you can control lots of these with awareness) …

1. what to do after speed of initial progress (“post FNP navel gazing”?), and the hard slog begins (take some time between this and your next bit of work planning the first few more important bits of the “hard slog” to do)
2. the design has a lot of similarities to other products “out there” (plan for some things you want to do that can be done in a variety of ways and pick a way that you have never tried before, if applicable)
3. you may have lost that intimate awareness of where each file is and what its role is for your project (go to the Finder or Windows Explorer or other, and locate your project, and see what’s there, now, preferably)
4. you lack intimate understanding of how to compile your code when it comes to porting it to another environment (the next IDE along, if applicable, may help with this (we hope))
5. the relationship of code to GUI can be baffling (practice the GUI to code linkage points, and look around more when succeeding, and remember that the more you practice the better you get)
6. the diversity of choice of environment is sometimes unnecessary and confusing (this is worth putting up with, especially as the more scenarios you test, the more solid your project is)
7. you may debug your way to a less efficient and elegant solution (leave debugging to only deeply embedded issues or problems, rather than using it in any way like a design tool)

Think Pro 2. on its own, makes it worth while to use IDEs, as you can see what is behind you and ahead of you, and it helps you envisage the “big picture” of what you want to achieve overall.

Here are links to some downloadable Xcode (on a Mac laptop) Objective-C programming source code of that initial “out of the box” look which you may want to rename to AppDelegate.h, AppDelegate.m, MyScene.h, MyScene.m and main.m

Later, we do a bit of tailoring to arrive at this look.

Here are links to some downloadable Xcode (on a Mac laptop) Objective-C programming source code of that “small amount of tailoring” look which you may want to rename to AppDelegate.h, AppDelegate.m, MyScene.h, MyScene.m and main.m

Here are links to some downloadable Xcode (on a Mac laptop) Objective-C programming source code of differences between the “small amount of tailoring” and the “out of the box” looks which you may want to rename to AppDelegate.h, AppDelegate.m, MyScene.h, MyScene.m and main.m

If this was interesting you may be interested in this too.