3rd Time a Charm?
by rennie moffat · in iTorque 2D · 11/06/2010 (3:15 am) · 15 replies
Hi there,
I just received my second rejection letter from Apple. In It is states the reason being.
Technically, what is happening from an iTGB side, is...
my emptyLevel.t2d, loads by default. In it, the level... acts as a "loadingLevel", in it that, All I have is artwork, and a single behavior. That behavior is attached to my "pressStartBtn". After a schedule, the btn, (currently off screen, is pulled onScreen. By pressing the pressStartBtn the player is brought into the mainMenu.t2d. What is happening with Apple, when they test it, the emptyLevel.2td loads but the pressStartBtnBehavior does not pull the pressStartBtn object into position to press. The user is forever in Limbo.
As I say I have sent in two copies, both with the same problem as a response. Both versions I sent in, had no behaviors.cs's. only the .dso were included. However, I believe all other scripts beyond, .dso's were included. This brings me to an idea, perhaps you can help....
The levels.t2d, have no visible.dso's only .cs's, However, when I look at the emptyLevel.cs, the pressBtnBehavior, is attached.
I am not sure what to do, any advice is appreciated. Ny only option now, I think is to send in a copy with the .cs behaviors included. Would this make a difference?
Cheers
Rennie
ps.
too any iTGB staff. I couldn't wait. hope that's ok. If you know what this means, you know what I mean. :))
I just received my second rejection letter from Apple. In It is states the reason being.
Technically, what is happening from an iTGB side, is...
my emptyLevel.t2d, loads by default. In it, the level... acts as a "loadingLevel", in it that, All I have is artwork, and a single behavior. That behavior is attached to my "pressStartBtn". After a schedule, the btn, (currently off screen, is pulled onScreen. By pressing the pressStartBtn the player is brought into the mainMenu.t2d. What is happening with Apple, when they test it, the emptyLevel.2td loads but the pressStartBtnBehavior does not pull the pressStartBtn object into position to press. The user is forever in Limbo.
As I say I have sent in two copies, both with the same problem as a response. Both versions I sent in, had no behaviors.cs's. only the .dso were included. However, I believe all other scripts beyond, .dso's were included. This brings me to an idea, perhaps you can help....
The levels.t2d, have no visible.dso's only .cs's, However, when I look at the emptyLevel.cs, the pressBtnBehavior, is attached.
I am not sure what to do, any advice is appreciated. Ny only option now, I think is to send in a copy with the .cs behaviors included. Would this make a difference?
Cheers
Rennie
ps.
too any iTGB staff. I couldn't wait. hope that's ok. If you know what this means, you know what I mean. :))
About the author
My thanks to Garage Games and the Garage Games Community combined with owned determination I got one game up, Temple Racer and I am looking to build more interesting, fun games for the mass market of the iOS app store.
#2
I am not worried about that. Someone may, but I made the game, the art, the music.... Simple scripts don't bother me because if someone does take it, well so what. It means they will only be forever one step behind me.
Get your own imaginations people! Just kidding, well, so you think if I pack it with the cs files it should go?
ps. I am going to pack both cs and dso.
11/06/2010 (2:33 pm)
Ahn, I am not worried about that. Someone may, but I made the game, the art, the music.... Simple scripts don't bother me because if someone does take it, well so what. It means they will only be forever one step behind me.
Get your own imaginations people! Just kidding, well, so you think if I pack it with the cs files it should go?
ps. I am going to pack both cs and dso.
#3
Sorry to hear about the rejection though, Rennie. Hopefully it will be third time lucky!
11/06/2010 (9:30 pm)
I used to feel a bit paranoid about the fact that someone could easily unpack the game and grab the code, but the more I think about it I tend to agree with Rennie. If someone is so desparate that they need to go and copy other people's stuff, I think that indicates that this person does not have the skills to create a game on his/her own and probably won't get very far anyway.Sorry to hear about the rejection though, Rennie. Hopefully it will be third time lucky!
#5
Why is this, what can I do? In short terms the behaviors ( I am assuming all, but at least one, the one to start the game is not being called)
11/06/2010 (10:07 pm)
Ok. I have just done some tests. With the simulator, on Debug, it works. However, on Shipping or Release, the behavior does not pull up, just as Apple was saying.Why is this, what can I do? In short terms the behaviors ( I am assuming all, but at least one, the one to start the game is not being called)
#6
11/07/2010 (4:33 am)
You could re-write your code to not use behaviors. Drastic, but it's a possible solution. 
#7
11/07/2010 (10:51 am)
Rennie, describe what you differently between a test build that you play on the device and the distribution build that you send to Apple?
#8
One thing I am thinking is, the location of the behaviors. Mine are in "~game/behaviors". I did switch them into "~scripts/behaiors and it did not work" HOWEVER... this response is a live feed...Upon switch them back into the game folder, it now works, on Shipping & Release!
WTHell?
I Will post later with more updates, but why would that occur? I swear to god I am not jerking anyones chain. So, in theory, if it all works now, it should work on Distribution Build.
11/07/2010 (1:49 pm)
I honestly do not think I do anything differnt. The only thing I may have done differnt is have the cs files or not.One thing I am thinking is, the location of the behaviors. Mine are in "~game/behaviors". I did switch them into "~scripts/behaiors and it did not work" HOWEVER... this response is a live feed...Upon switch them back into the game folder, it now works, on Shipping & Release!
WTHell?
I Will post later with more updates, but why would that occur? I swear to god I am not jerking anyones chain. So, in theory, if it all works now, it should work on Distribution Build.
#9
Fingers crossed. I hope third time is a charm.
Thanks.
11/07/2010 (2:09 pm)
ok. So, just for the record. I have uploaded again. It worked on the simulator on Shipping and Release. I set it to Distribution, built it, compressed it, and have uploaded. Fingers crossed. I hope third time is a charm.
Thanks.
#10
Your workflow should be something like this:
- uninstall app from device
- clean / build (shipping) to the device
- run tests
- if all tests pass then build and upload distribution (don't change anything code wise)
- otherwise repeat the above steps until all tests pass
11/07/2010 (2:15 pm)
Rennie, have you tested on the device for shipping and release? I think you should ignore any simulator testing - it does not behave in the same manner as that deployed on the device. Apple only test on the devices.Your workflow should be something like this:
- uninstall app from device
- clean / build (shipping) to the device
- run tests
- if all tests pass then build and upload distribution (don't change anything code wise)
- otherwise repeat the above steps until all tests pass
#11
I have resent it, I will be purchasing another, this week? if it doesn't turn up.
I did uninstall from the Simulator, reuploaded, cleaned, ran tests. Again, hopefully this does it.
So for now, I will hope the clearance from the Simulator is enough.
11/07/2010 (2:21 pm)
I would, but I recently lost my iPod. Oops.I have resent it, I will be purchasing another, this week? if it doesn't turn up.
I did uninstall from the Simulator, reuploaded, cleaned, ran tests. Again, hopefully this does it.
So for now, I will hope the clearance from the Simulator is enough.
#12
Some things you should notice when switching to the other build target in Xcode:
- Switch to the new build target
- Delete common and game folders reference from Xcode
- Attach them again
- Delete the build folder or Cmd+Shift+K to clean the old build
- Right click on common and game, then select Compile, this is to make sure the new folders get copied into the build package.
- Build project.
Cheers.
11/08/2010 (12:39 am)
Rennie,Some things you should notice when switching to the other build target in Xcode:
- Switch to the new build target
- Delete common and game folders reference from Xcode
- Attach them again
- Delete the build folder or Cmd+Shift+K to clean the old build
- Right click on common and game, then select Compile, this is to make sure the new folders get copied into the build package.
- Build project.
Cheers.
#13
11/08/2010 (1:22 am)
Do you think my method was wrong despite it working on the simulator in both Shipping and Release mode?
#14
You have to test on the real device before uploading any binary.
Testing on simulator is like making 25% of the phase test.
You have to test on real device, and even on multiple different devices.
If you get a new device next week, wait next week to have it and test on it before uploading any binary.
It is a requirement to test on real device when developing with Cocoa/objective-C, but even more when using a middleware as iT2D.
Nicolas Buquet
www.buquet-net.com/cv/
11/08/2010 (7:55 am)
Yes, it is absolutely wrong.You have to test on the real device before uploading any binary.
Testing on simulator is like making 25% of the phase test.
You have to test on real device, and even on multiple different devices.
If you get a new device next week, wait next week to have it and test on it before uploading any binary.
It is a requirement to test on real device when developing with Cocoa/objective-C, but even more when using a middleware as iT2D.
Nicolas Buquet
www.buquet-net.com/cv/
#15
Thank you.
11/08/2010 (12:48 pm)
Ok. Thank you for the advice. For now, I will leave that binary. I will purchase a new iPod this week. and test on it. If it works fine, which it did, when I uploaded the original binaries. I will upload that, if it does not work, I will follow those steps.Thank you.
Torque Owner Scott Wilson-Billing
MeYuMe
I always include the CS files and NO DSO files. I know many other's don't but I always wanted the game compiled on the actual device. Now, it does mean somebody could grab your source code by unpacking the game.