2nd iTorque RPG Released!
by Watermark · in iTorque 2D · 11/21/2012 (9:25 pm) · 6 replies
Hey everyone,
Our second iTorque RPG "Sorceria 2: Sunken City" has been released to the App Store! Woohoo!
You can download it here:
https://itunes.apple.com/us/app/sorceria-2-sunken-city/id578939010?mt=8
The game was created in iTorque 1.5.0, and so far it passed Apple's inspections with no problem. It is based on the engine of our first RPG Sorceria 1, but it's alot cleaner and the flow should be better. Overall it's a better game than the first one. Don't expect it to be Final Fantasy, but you can probably get a few hours of entertainment out of it.
So here's another dev team that wishes the new Torque2D comes out soon!
Cause the good news is iTorque 1.5.0 still works with Apple. The trepidation is we don't know how long this will last. And it has no iPhone5 support.
One thing I do wish can be improved with the new iteration of the Torque engine is the collision algorithm of the tilemaps. Currently, there are "stuck bouncing" problems. Say your hero is 32x32 pixels. Then you make a tilemap of 32x32 blocks. Now, when your hero walks between two blocked tiles that are spaced 32 pixels apart, in other words a corridor of width 32 pixels, he will get stuck and start "bouncing" and there's no way out of it. This was a major problem in Sorceria 1 and got us lots of flame mail from customers.
So the current work around is to make the collision square of the hero smaller than 32x32, something like 15x15. This works mostly. Still, wish this could be solved.
Anyway, happy gaming!
Our second iTorque RPG "Sorceria 2: Sunken City" has been released to the App Store! Woohoo!
You can download it here:
https://itunes.apple.com/us/app/sorceria-2-sunken-city/id578939010?mt=8
The game was created in iTorque 1.5.0, and so far it passed Apple's inspections with no problem. It is based on the engine of our first RPG Sorceria 1, but it's alot cleaner and the flow should be better. Overall it's a better game than the first one. Don't expect it to be Final Fantasy, but you can probably get a few hours of entertainment out of it.
So here's another dev team that wishes the new Torque2D comes out soon!
Cause the good news is iTorque 1.5.0 still works with Apple. The trepidation is we don't know how long this will last. And it has no iPhone5 support.
One thing I do wish can be improved with the new iteration of the Torque engine is the collision algorithm of the tilemaps. Currently, there are "stuck bouncing" problems. Say your hero is 32x32 pixels. Then you make a tilemap of 32x32 blocks. Now, when your hero walks between two blocked tiles that are spaced 32 pixels apart, in other words a corridor of width 32 pixels, he will get stuck and start "bouncing" and there's no way out of it. This was a major problem in Sorceria 1 and got us lots of flame mail from customers.
So the current work around is to make the collision square of the hero smaller than 32x32, something like 15x15. This works mostly. Still, wish this could be solved.
Anyway, happy gaming!
About the author
Three iTorque 1.5 games published: Sorceria 1: The Mad Doctor RPG Sorceria 2: Sunken City Sagas: RPG Boardgame and Name Generator For more info see our site: http://wmrpg.weebly.com
#2
When I first started, your movement pad was actually my model. First I tried it with the GUI buttons + MoveTo, but you couldn't "hold down" so you had to press the button everytime you move a tile, which got really annoying. So I changed the buttons to onscreen animated sprites and basically just set the velocity of the hero character on touch down and reset the velocity to 0 on touch up. This actually has some problems as sometimes your character won't stop moving because the touch up wasn't detected in time.
If you don't mind me asking, how do you get your character to move a certain number of tiles when pressed down on your pad? See, my logic goes, when you press the control pad, the sprite calls MoveTo, and then you call the next MoveTo when the character arrives on Position, but see the button is always pressed down so when would you call MoveTo? What's amazing about the GS pad is that the hero moves in exact tiles, and stops when you release the pad.
Wow, you guys wrote all your own custom collision script? I was just lazy and used the default one. Thanks for the tip. I'll try it out.
11/23/2012 (5:00 pm)
Hey! It's the Guardian Saga guy! You guys made a great game. When I first started, your movement pad was actually my model. First I tried it with the GUI buttons + MoveTo, but you couldn't "hold down" so you had to press the button everytime you move a tile, which got really annoying. So I changed the buttons to onscreen animated sprites and basically just set the velocity of the hero character on touch down and reset the velocity to 0 on touch up. This actually has some problems as sometimes your character won't stop moving because the touch up wasn't detected in time.
If you don't mind me asking, how do you get your character to move a certain number of tiles when pressed down on your pad? See, my logic goes, when you press the control pad, the sprite calls MoveTo, and then you call the next MoveTo when the character arrives on Position, but see the button is always pressed down so when would you call MoveTo? What's amazing about the GS pad is that the hero moves in exact tiles, and stops when you release the pad.
Wow, you guys wrote all your own custom collision script? I was just lazy and used the default one. Thanks for the tip. I'll try it out.
#3
11/24/2012 (1:03 pm)
Congratz Watermark. I downloaded it and didn't get to play it much yet but it looked great. RPGs are extremely tough to do but looks like you made a really good one. 
#4
The way we handled our player movement is when you pressed a direction on the dpad we call our move function on the player. The move function will check if the tile we want to move into is marked for collision, if it's clear, we call moveTo on the player to move him to the next tile and set a isMoving flag on the player. Any subsequent calls to move while the isMoving flag is true are ignored. Then in the player's onPositionTarget callback, we set isMoving to false again, and then immediately check the controller state. If a direction is still being pressed we call move again right away. That way you don't get a hitch while you're walking because of a 1 frame lag between moveTo calls.
11/24/2012 (2:34 pm)
@Watermark:The way we handled our player movement is when you pressed a direction on the dpad we call our move function on the player. The move function will check if the tile we want to move into is marked for collision, if it's clear, we call moveTo on the player to move him to the next tile and set a isMoving flag on the player. Any subsequent calls to move while the isMoving flag is true are ignored. Then in the player's onPositionTarget callback, we set isMoving to false again, and then immediately check the controller state. If a direction is still being pressed we call move again right away. That way you don't get a hitch while you're walking because of a 1 frame lag between moveTo calls.
#5
Thanks a lot! Why didn't I think of that? This is very good advice.
@Johnny:
Thanks Johnny! I think I coded the RPG cause I was too naive about how much work it would actually take when I first started. Back then I naively thought I could do it in a month. To all you beginners reading this, it took me 9 MONTHS of diligent part time work (about 3 hours a day) to finish the RPG engine. Whew, just like delivering a baby. Being naive was actually good, cause I never would've written this game if I knew how much work was going into it. It's worth it.
So to you beginners, if there's something you want to write, what the heck, just do it.
11/25/2012 (5:05 am)
@Adam:Thanks a lot! Why didn't I think of that? This is very good advice.
@Johnny:
Thanks Johnny! I think I coded the RPG cause I was too naive about how much work it would actually take when I first started. Back then I naively thought I could do it in a month. To all you beginners reading this, it took me 9 MONTHS of diligent part time work (about 3 hours a day) to finish the RPG engine. Whew, just like delivering a baby. Being naive was actually good, cause I never would've written this game if I knew how much work was going into it. It's worth it.
So to you beginners, if there's something you want to write, what the heck, just do it.
#6
Nine months is great, especially working alone!
I have been learning about game programming as a hobby for 30 years and have yet to ship anything on my own - you guys are rocking! Keep it up!
11/25/2012 (4:21 pm)
Pretty good advice from everyone giving it here - but I'd say that no matter what you are going to do you should be aware that there is going to be a ton of work involved. Probably far more than you initially anticipate. If you love it, you will finish it - just don't let yourself be discouraged. Making a tiny game is no trivial task - making a great game is a large task at the least.Nine months is great, especially working alone!
I have been learning about game programming as a hobby for 30 years and have yet to ship anything on my own - you guys are rocking! Keep it up!
Torque Owner Adam Chard
9th Bit Games
About your collision issues, have you considered not using the physics system at all for your tile collisions? In our RPG (https://itunes.apple.com/us/app/guardian-saga/id451887140?mt=8) the player could only move tile-by-tile, so it was really easy for us to just check the tile in front of the player before they move to see if it was flagged for collision (we literally put the word "collision" in the string field on the tile).
Even if you can move freely, you could still easily calculate what tiles your player's "collision rect" overlaps with, and manually check if any of those tiles are marked for collision.