I'm trying to make a game that includes playing cards.
I have a sub class of BorderedMorph that I added to all of the decks.
I have sub class of PlayingCardDeck that I implemented the game deck behaviour in.
I didn't touched all of the dragging and dropping features in the subclass, and I get the same error you get when you try to drag and drop this:
g:= PlayingCardDeck new.
g newDeck.
g layout: #pile.
g openInWorld.
how can I repair this bug and make my game draggable, so I will be able to move it on screen (not only by pressing the scroll wheel in).
the problem is in the PlayingCardMorph because when I try to move empty deck I can do it.
ok my issue is resolved.
the solution for me was to make sub class for PlayingCardMorph
and adding the following method:
handlesMouseDown: aMouse
^false
hope it helps any one that needs it.
Related
I can take answers in either Swift or Objective-C.
I'm using SceneKit, and I have a 2D OverlayScene that's displaying on top of the 3D GameScene. I'd like GameScene to be able to reference back and forth between OverlayScene so that I can detect taps, run functions, etc. But whenever I try to create an instance of Overlay, I get various crashes. I have tried a few things, including but not limited to:
/* THIS IS IS MY 3D GAME-SCENE */
// Some crash about not using "init(size:CGSize)".
let overlayScene = SK_OverlayScene()
// There is no such thing as "self.size" in SceneKit.
let overlayScene = SK_OverlayScene(size: self.size)
// Some crazy crash I can't figure out at all.
let overlayScene = SK_OverlayScene(size: myGameViewController.sceneView.bounds.size)
In other words, I have tried many different solutions. If you don't believe that I did one of those solutions correctly, then ask me for the exact code and I'll give it to you.
My question is this: am I even going about this the correct way? Should I be using instances of the overlay scene, or should I be trying to contact the scene directly? I'm not really sure what's wrong here, that's why I'm asking for help.
EDIT: I have already tried to move the code inside OverlayScene's init(size:CGSize) into a simple init(), but that is also giving me problems.
I've come across a problem to which the simplest solution would be to extend the length of a UIGestureRecognizer. What I mean is that I need the iOS device to still believe the user has their finger on the screen for about 0.1 seconds after they release it. I need the device to think that the finger is in the exact same position for the 0.1 seconds as it was when the user released this.
Any help as to weather this is possible would be greatly appreciated!
Thank you!!!
EDIT:
Sorry for the late reply, I've been really busy with work.
To elaborate, I'm using a set of classes made by Alan Quartermain called AQGridView. It's a class that strongly resembles UITableView; however, it displays data in a grid instead of a list. There appears to be a bug where (if I understand correctly, and I may very well not) the data of the grid is reloaded before the delegate method, that is called when a user ends a UIGestureRecognizer, finishes if the user releases their finger while dragging a cell (from one grid index to another) very quickly. This causes a graphical glitch (which can be recreated in the springboard example that comes with the class set) where the dragging cell appears to settle one cell before or after it's appropriate location, and then quickly jumps to it's proper location. I believe this is because there is a brief period, when the user releases their finger, where the grids count is -1 of what it is when the cell settles.
This is a poor explanation of the problem, but the best I could come up with. As well, I'm a relatively new developer and could be way off on the cause of the problem. That is why I believe the most appropriate fix would be to extend the gesture length by a very small amount. If anyone wants to take a look at the AQGridView classes (https://github.com/AlanQuatermain/AQGridView/) I would really appreciate it! But if possible a simpler fix would just be to simulate the touch that the user inputed right before they released their finger so that the desired animation occurs.
Inside touchesEnded delegate method, start timer for 0.1 second and perform your selector.
You can even, subclass UIGestureRecogniser and implement your own gestures, Check the first answer of this question.
See : custom iOS gesture
I've been considering an app now that implements a drag and drop sort of idiom from maybe a side pane or a drawer, etc. what I can't wrap my head around are how to keep reference to the objects I drop. I mean; it would be easy if it was just drop the object, then let it alone, but I want more manipulation after the fact.
My brain just cannot wrap around the concept of creating objects out of thin air to place on the 'canvas', or having preset objects (which I imagine would be limited, cumbersome and awkward) already on the canvas that would then just be activated and manipulated easily, seeing as the references to them are created before the fact (my apologies for the loose term 'reference', I mean something like selecting the object and having it's unique properties recognized or displayed).
There must be something I'm missing. So, I wonder how one might go about implementing drag and drop with interface and manipulation with the dropped object after the fact or maybe sample code or a link to a git or svn repo? (something like how MIT's scratch, or Xcode's interface builder might work).
For clarity's sake, I know how to go about fiddling with drag and drop thanks to DragKit, but not about editing 'properties' on the object dropped onto the 'canvas', and I would like there to be a near infinite amount of objects that can be dropped on the canvas, yet a set amount of items in the drawer/side view.
If I'm understanding your question correctly, you want to be able to drag objects onto a canvas and then manipulate their properties individually. For instance, you'd drag square views onto the screen and then increase its size or change its color.
In order to do something like that, I would have a NSMutableArray or an NSMutableSet that would hold all of the on canvas objects. Then when any interaction comes, you could either dynamically generate gesture recognizers if the objects are UIViews or a subclass. Then in the target of the gesture recognizer you would use the recognizer.view property.
Or you would have to check which object on the canvas you were currently manipulating. That would be done by iterating through the array and seeing which object equals the one you are touching.
Is there anything that you are trying to do but is not working? Have you written any code in attempt to do this?
I am a relative novice who is teaching himself Objective-C on Xcode to develop some simple iPhone game apps. I have done some reading on this but fear I'm missing something basic and obvious.
I made a simple "Hello, World" and, based on opinions in various forums, I decided to do a Tic Tac Toe. I found a nice video and built a version based on that, which ran fine. However, my own interpretation is already running into trouble.
I'm using Xcode 4.0.2 on Snow Leopard. I chose a View-Based Application template and pulled a large image view onto the layout to hold a PNG called board. I put nine small image views on the large one to hold individual cells for X and O (and created some PNGs for the images). I just attached board.png to the big image view through IB so that works fine.
Next I tried to associate cell 1 with x.png by assigning it to a variable called ximg. This is all set up in the view controller's viewDidLoad method like so -- "ximg = [UIImage imageNamed:#"x.png"];". I then used the code "cell1.image = ximg;" -- also in viewDidLoad. X appeared on the board when I built and ran.
My next step was cell 2. I wanted to use a variable in a custom method this time, so I could change it in the future. I declared a method "- (void)setcell2" (bad camelCase, I know). I put the following method into my view controller implementation file:
-(void)setcell2 {
cell2.image = ximg;
}
I also added the following message to viewDidLoad -- "[self setcell2];"
As you'd guess, I was figuring that when the app loaded, viewDidLoad would send that message to setcell2, which would attach another X in the second box, but this didn't happen.
If someone could give me some idea of what I'm overlooking, I'd be gratified. Example code is appreciated but I can figure that out with time. This is not homework. Thanks for reading!
Most likely you haven't set your cell up properly in Interface Builder. Make sure you have connected the property to the outlet.
I am currently trying to create a menu system for a game and cannot arrive at any really sound way to do it. There are several menu screens, each of them non-trivial, so that I would like to keep these as separate classes. The main problem I am having is passing control between these menu screens.
I tried building each of the screens as a singleton and call one screen from the other directly, ie. something like [[MainMenu instance] display] in Objective C. This is a bit messy, because (1) I have to write the singleton boilerplate code for each of the menu screens and (2) the classes get dependent on each other, sometimes I have to code around circular dependencies etc.
I thought about making the classes fully static to get around the instance management (which is a bit extra in this case, since there really is just one instance of each screen). But this also looks quite ugly, especially with Objective C having to “fake” class variables by declaring them static.
Then I thought about some “manager” class that would create the instances and pass the control around, but I am not sure introducing an extra class would solve the problem, especially if this class was to be named Manager :-)
I should note that I do have a working system, it just doesn’t feel very nice. By which I mean there is a bit of code duplication going on, if I am not careful the thing might hang, and so on. Any ideas? I am aware that this is underspecified, so that the discussion will probably be more of a brainstorming, but I am interested in the ideas anyway, even if they do not outright solve my problem.
Update: Thank You all for the ideas. What I did in the end:
I reworked the menu contents (buttons, graphics, etc.) to fit under one interface called ScreenView. This is a general interface that looks like this:
#protocol ScreenView
- (void) draw;
- (BOOL) handlesPoint: (CGPoint) p;
- (void) appearWithAnimation;
- (void) disappearWithAnimation;
- (BOOL) hasFinishedAnimating;
#optional
- (void) fingerDown;
- (void) fingerUp;
#end
Thanks to this protocol I was able to throw away all the specific menu screens and create a general menu screen that takes a list of subviews to display and handles all the presentation like drawing, transitions, events and such. This general menu screen does not get subclassed much, because most of the menu screens are happy simply displaying a list of subviews. This would be the V in MVC.
Then I also created a controller class that handles all the events for a certain menu screen. (Obviously the C in MVC.) The root controller class handles the instance management, transitions between menus and some other little things. Most of the menu screens get a customized subclass of the controller that handles the events from the buttons and other subviews.
The number of classes got up, but the code is much cleaner, does not repeat itself and is less prone to errors. The instance management is still not perfect, but I’m reasonably happy with the design. Once again, thank to all who answered.
One of the tricks I learned to decent design is always separate your data from your code. This will do WONDERS for your specific problem.
By this I mean that the menu items (strings) and relationships between the menus should be stored somewhere either in an array or a separate file (and read into an array).
You then use this array to instantiate all your menu classes.
Once you recode it to work this way (I've done this with menus), all your code will fall into place, you'll also factor out--90% of your menuing code (each menu will no longer be it's own class, just the same class instantiated with its own unique data.
The target of the menu items are stored in the "data" as well (as method pointers or class instances).
I think a MenuManager class would be the way to go. You'd have one Menu base class which all the menu screens derive from, and the manager would have a pointer to the currently active menu screen. It could also, for example, keep track of previous menu screens for easy use of back buttons on menu screens in arbitrary menu screen calls. Maybe just use a std::vector for that so you don't have to recreate the previous menu screens when going back (this would also prevent loss of entered information, like in an Options menu with an Advanced submenu).
Putting all the contents of the menus into a dictionary, dumping to a plist and reading each as necessary by the menu screens is likely the simplest route but in all honesty, you should consider taking a more MVC-centric approach to solving the problem. The screens should be for presentation of data not the storage of it. If you provide for a clean separation of the data from the views, the problem solves itself.