I am making a game for my psychology lab that has different scenes (jungle, sea, desert, moon, dungeon ect.) but the character behavior for each scene is essentially the same. Is it possible to write a class that will have all of the essential behaviors and animations that every sprite will need and then have subclasses that inherit from this class (I would only want to change the sprites image based on the scene in each subclass).
Sorry for late the answer, but I didn't see this until now. What you are after can fairly easily be achieved in Spritebuilder, without the need of subclassing. At least, it works well if your characters are composed of a CCNode with animated sprites. Lets say you have a ccb file set up with all the animations called JungleCharacter:
Right click the JungleCharacter file and choose "Duplicate". Now, in the new file (lets say we call it SeaCharacter) you select each sprite and in the 'Item properties' pane (on the right hand side) you can change the sprite frame. So, if you'd have a sprite frame called "JungleCharacterLeftArm.png", you'd change it to the equivalent "SeaCharacterLeftArm.png".
If it's to tiresome to do this in Spritebuilder, you could opt to do it in your favorite text editor, since ccb files are xml files. You'll find them in the "Packages/SpriteBuilder Resources.sbpack" folder (right click and select "show package contents"). If you set up your image assets in a smart way like "Jungle/LeftArm.png", "Sea/LeftArm.png" you can then do a quick find and replace, replacing "Jungle" with "Sea" (you get the idea).
Hope this helps!
Related
I've watched the WWDC 2014 session (#608 "Best practices for building sprite kit games") a couple of times and I just want to clarify the purpose behind using .sks files. Am I supposed to put separate assets into each .sks file? Here's a little bit of background into what I'm doing. I'm creating a Mac app that will text piano students to play chords using a MIDI keyboard. Chords will appear on the screen and they'll play them one by one and get a score. Here's a mockup of what the app may look like. Side note: for those that may know music, we're using the numeric version of chords instead of explicit names like Cm, etc.
Would I have a separate .sks file for each element of the UI. For instance, one for the green timer bar, one for the piano keys, etc. The example that they use in the video is a pretty simple one. I am subclassing SKSpriteNode for the timer and on-screen piano so how would I handle the resources for those. They are not static objects and they will change either over time (timer) or due to user input (keyboard)
I really want to organize my project using best practices. Please help. Thanks in advance.
Sks files are serialized SKScene objects. The intent is to provide something like interface builder for constructing SKScene scenes visually. The common use case is to layout complex backgrounds or levels and define starting positions. You would only have one file per scene in many cases. However you can use the sks files to organize and serialize conceptual components of a scene, as demonstrated in versions of the Apple Adventure sample code released since the sks format and scene editor were introduced with Xcode 6
In the screenshot above, you could organize the project into sections that are fairly generic and reusable, like the keyboard for one file and the hud atop the scene for another file. However, you could put them all in one file, then duplicate the file for variations on a theme.
I have a question regarding NSMenuItems.
What I'm trying to do is replicate a java GUI using native OS X components, therefore the language I am using is Cocoa. What I am trying to do is to get every menu item to have an image and then, beside it, some text.
I have already done some research into it and my first port of call (as always it seems lol) was the apple docs which had this handy example which illustrates how to embed views inside menuitems:
https://developer.apple.com/library/mac/#samplecode/MenuItemView/Listings/MyWindowController_m.html#//apple_ref/doc/uid/DTS10004136-MyWindowController_m-DontLinkElementID_8
Being relatively new to cocoa, I was thinking I would have to override one of the drawing methods from NSMenuItem. Not really sure though.
Another idea that I was toying with was creating a custom view that held a image and some text.
Any other ideas/validation or discussion would be most appreciated.
Thanks all!
Oh and the GUI creation is being done by hand no interface builder.
Okay, so I now have menu items with icons beside them. For anyone who is interested here it is ( i've not done a leak analysis on it or anything).
First things first, put all of the images you want into the "Resources" folder (thats what its called in xcode 3.1.4).
Now, for example, after we have all the images, we want to use images called "eraser.png" and "eraser_on.png" and I want to attach these to the 3rd menu item. In order to achieve this we do the following :
The code below will get the menu item at position 3 in the menu
NSMenuItem *item = [ nameOfPopUpButton itemAtIndex:2];
The code below will set the image for the menu item to be "eraser.png"
[ item setImage: [ NSImage imageNamed:#"eraser"] ];
That's you set the image for the menu item (which will be on the left hand side of the text aka before the text).
If you want different images for the different states, eg when the user presses it, use this method (not tested myself but its sounds sensible :D and the function is straight out the api)
[item setOnStateImage: [ NSImage imageNamed:#"eraser_on" ] ]
You can however leave it nil or not set it at all and it will go the default color
Hope this helps someone.
Pieced this together from: https://developer.apple.com/library/mac/#samplecode/MenuMadness/Listings/Controller_m.html#//apple_ref/doc/uid/DTS40008870-Controller_m-DontLinkElementID_4
Thanks :)
If you need to do this you have the right idea in creating a view with image and label subviews.
BUT: don't do this. Creating a "native" application is not primarily about your choice of language (which is Objective-C, btw, not Cocoa; the latter is a collection of development frameworks implemented in Objective-C). It's about conforming to the platform.
On OS X (and iOS), more than probably any other platform, consistency in UI design is paramount. Users know when an application looks strange, and having icons next to each menu item (something I certainly have seen in Java apps) is definitely strange and unnatural on OS X. Users will be irritated at best, confused at worst.
So my advice is to either follow the Human Interface Guidelines (and save yourself a lot of work as a nice side effect) or just stick with your existing Java application.
If you want to provide quick iconic access to common functions, the recommended approach on OS X is to use a toolbar.
I just wanted to know how you could implement a bookcase, like in iBooks, into your iPhone app.
I presume you would need to use a UIScrollView, but then I read somewhere that you need to use a UITableView. Which is it?!
You'd use code that others have already written, such as AQGridView.
I'm not sure if there's a better way, but you could create multiple small views or images (these would represent each book) then add these small views/images to the subview of a larger view in a linear format (leaving a space between each element). Then just set the background of your larger view as an image of a bookcase. Sorry I don't know of a better way.
And for the above solution I would use a UIScrollView.
You can implement it anyway you like, but it seems to me that a UITableView would be the easiest (which will scroll anyway). All of the magic will happen in your UITableViewDataSource, which is where you will decide what books are placed on what row.
Once you have decided which books to display you will have create a custom tableview cell that draws the appropriate objects.
To be honest, while not too difficult of a task, it will take a lot of effort to get looking right. If you are not comfortable with custom drawing then be prepared to spend time learning about the various image/graphic APIs.
I am working through Aaron Hillegass' Cocoa Programming for Mac OS X and am doing the challenge for Chapter 18. Basically, the challenge is to write an app that can draw ovals using your mouse, and then additionally, add saving/loading and undo support. I'm trying to think of a good class design for this app that follows MVC. Here's what I had in mind:
Have a NSView-subclass that represents an oval (say JBOval) that I can use to easily draw an oval.
Have a main view (JBDrawingView) that holds JBOvals and draws them.
The thing is that I wasn't sure how to add archiving. Should I archive each JBOval? I think this would work, but archiving an NSView doesn't seem very efficient. Any ideas on a better class design?
Thanks.
Have a NSView-subclass that represents an oval (say JBOval) that I can use to easily draw an oval.
That doesn't sound very MVC. “JBOval” sounds like a model class to me.
Have a main view (JBDrawingView) that holds JBOvals and draws them.
I do like this part.
My suggestion is to have each model object (JBOval, etc.) able to create a Bézier path representing itself. The JBDrawingView (and you should come up with a better name for that, as all views draw by definition) should ask each model object for its Bézier path, fill settings, and stroke settings, and draw the object accordingly.
This keeps the knowledge of how to draw (the path, line width, colors, etc.) in the various shape classes where they belong, while also keeping the actual drawing code in the view layer where it belongs.
The answer to where to put archiving code should be intuitively obvious from this point.
Having a whole NSView for each oval seems rather heavyweight to me. I would descend them from NSObject instead and just have them draw to the current view.
They could also know how to archive themselves, although at that point you'd probably want to think about pulling them out of the view and thinking of them more as part of your model.
Your JBOval views would each be responsible for drawing themselves (basically drawing an oval path and filling it, within their bounds), but JBDrawingView would be responsible for mousing and dragging (and thereby sizing and positioning the JBOvals, which would be its subviews). The drawingView would do no drawing itself.
So far as archiving, you could either have a model class to represent each oval (such as its bounding rectangle, or any other dimensions you choose to represent each oval with). You could archive and unarchive these models to recreate your views.
Finally, I use the JB prefix too, so … :P at you.
I am a physics teacher in London and I am trying to learn processing.js
To make teaching resources a very important technique is to be able to drag shapes around. Although I know how to do this in PJS, I have found that the code for having several draggable objects quickly gets messy. (especially if the object is "locked", so that it does not matter if the cursor goes off the object)
Does anybody know how to run the dragging spript from a separate file? i.e. so that the main script calls the dragging script for objects? The idea is that you would draw shapes and simply make them draggable, with the dragging code in a separate file? This would make the creation of teacher resources a lot easier.
It would be great if people could provide some ideas on this. I have seen the drag demos on the main PJS website, but I am looking for something quicker/easier.
Many thanks
Matt Klein
ruby_murray1[AT]hotmail.com
Well, I do processing.js in pure javascript code without bothering with the Processing syntax but it should go something similar:
Make the objects that you want draggable adhere to a Draggable interface, the draggable interface indicates what is draggable and provides a method to move an object
When drag starts, see if there is a Draggable object under the mouse that you want to drag, store it locally and use the Draggable interface method to move the object around. This way your local dragging code is generic to any Draggable object and objects handle their own movement.
On drag end, remove the Draggable object from your local store (and stop calling its move method).
You could pull out this entire dragging logic into an external file as well, as long as you hook it into the correct mouse events.
About Interfaces: http://forum.processing.org/topic/class-interface-block-example