Posted: 20th Sep 2011 23:04
Hi all, we have recently moved across from a different SDK using C/C++ in Windows (for iOS). One of my biggest questions when moving over was how difficult it would be to re-code our app in AGK. So I downloaded the trial, and for those that share the same concerns, I can tell you that it was incredibly easy to move it across to Tier 1. AppGameKit is an amazing tool and I am definitely purchasing the full version (infact, I already have!). Tier 2 may even be easier as my code was written in C/C++ anyway.

The game we created is called 'BoxShot' and is available on the Apple Store.

http://itunes.apple.com/gb/app/boxshot/id440969020?mt=8

I have successfully re-coded it in Tier 1 which I have attached below if you fancy taking a look. Its a simple skill-stop/reaction game. The only difference is that we have a global leaderboard which is not in the AppGameKit version as there is no URL support in Tier 1 yet (I believe). Oh, and the HighScore does not save as yet...

Feel free to provide any comments/feedback...
Posted: 21st Sep 2011 2:51
Pretty cool, little game.

My reactions are not that great though, I only managed a score of 30 after numerous tries.
Posted: 21st Sep 2011 3:46
My reactions are not that great though, I only managed a score of 30 after numerous tries

lol
Here was my 3rd or fourth attempt... (see attached)
I hit the extra life then a 100

I like the game but it does seem like it could be too difficult for some people.
If the green box you land in was wider maybe, then you could still get some points if you didn't hit it perfectly centered. (you would get a bonus for a perfect hit)
That might make the gameplay last longer and make it more fun for the 'reaction-challenged'.
Then, the green box could shrink as you progess.
Just a thought.

Very simple but fun game.
I wish you much success on your sales.
Posted: 21st Sep 2011 4:00
Here is a gameplay video ....(see attached)
I really like your animated intro for the menu.

Another idea might be to slow the red box down some at the beginning, and then increase the speed a little with each successful landing.
Posted: 21st Sep 2011 10:41
Great work! Nice to see another application published so soon.

Rick
Posted: 21st Sep 2011 11:12
Great work! Nice to see another application published so soon.


Umm, the published game wasn't made with AGK.
Posted: 21st Sep 2011 11:56
Good game, I must be getting old though as my reactions are so slow.
Posted: 21st Sep 2011 13:18
Thanks for all the replies...

Your right, it is quite tricky, it seems to be a little less responsive on the PC than on the iPhone. Makes it trickier. Having said that, the more you play it the better you get. Attached is a screen print of our top 10 on the leaderboard, people are achieving scores well into the thousands (I'm on there to ha!).

@Conjured Entertainment, slowing the box down is definately a good idea. This was something we wanted to do but the previous SDK made it almost impossible. I'm looking forward to enhancing this game with AppGameKit!

Do you know if its possible to alter the FPS in game? Would be easy to try it out, but I'm at work so can't test it... I was thinkg that we could simply use SetSyncRate to increase/decrease the speed (or does this only work at start up?).

Again, thanks for all the comments.
Posted: 21st Sep 2011 14:24
You don't want to do it by altering the FPS. Do it by actually changing the speed of the box.
Posted: 21st Sep 2011 15:25
Thanks Bursar, thats kinda what I thought... I'll have to rethink this then. The previous SDK only supported 30 FPS so we used each frame as a way of incrementing a 'count' variable, this was then used to move the box... For example, if count = 1, move box to position 1, if count = 2, move box to position 2 so on and so on... (by the way, I'm new to coding, there is probably a much easier way than this ha)...
Posted: 22nd Sep 2011 4:20
Do you know if its possible to alter the FPS in game?


Why couldn't you use a sleep(x) in your main loop before you reposition the red box, whereas x would start out high and get reduced as you increase difficulty, thus making it faster?
The value of X wouldn't have to be much to make the box's speed noticably slower.
Just make sure to check for values less than one and make them = one if they are...
if x < 1 then x = 1
... somewhere after where you change x's value and before you call the sleep(x)
That ensures that you do not call a negative number and go back in time as Jeremy has attempted.
Posted: 22nd Sep 2011 16:13
@Conjured Entertainment, Sleep sounds like a good option... There was no such function in the previous SDK. I'll give that a go, thanks...
Posted: 22nd Sep 2011 17:19
@Conjured Entertainment, actually, thinking about it abit more... I assume when you use the 'sleep' command, it quite literately stops running the code?? This would be a problem as if the user clicks during the 'sleep' times, then the button wouldn't respond... I know its only a split second, but being a reaction game I think its critical that it stops flawlessly...

I'll have a play with a few other ideas, perhaps using Timer or something?
Posted: 22nd Sep 2011 18:48
perhaps using Timer

That's how I'd do it.

Do
Get the time that this cycle starts.
If (thisTime - lastTime) > 1/desiredFPS Then game stuff

thisTime = lastTime
Loop

Something like that anyway. Have a look in the help for the timer based movement examples.
Posted: 22nd Sep 2011 18:54
Since the app is set for say 30FPS, you know that each loop takes 33,3 milliseconds, so if you want the box to wait say 2 frames, make a counter that increase by 1 at every loop, then make an IF ENDIF checking if the counter reached 2, then set counter back to 0 or 1 and do the movement. For longer pauses, wait for higher loop counts.

Or use timer based counters like Bursar said.
Posted: 23rd Sep 2011 1:15
I assume when you use the 'sleep' command, it quite literately stops running the code?? This would be a problem as if the user clicks during the 'sleep' times, then the button wouldn't respond... I know its only a split second, but being a reaction game I think its critical that it stops flawlessly...

lol
Good thinking.
That is why not to use sleep.

I guess use of a timer would be better.