Castleguard2 Update (Submitted)

Recently checked out the dev's blog to see that the update has been submitted (on the 24th)!
(I am not the developer)
-------------------------
It has been awhile since my last update, but I’ve been insanely busy. I had submitted an update a little while ago to address the major concerns from the initial pre-release, but decided to self-reject it. I really didn’t want to be judged again without having the majority of features in that were slated for official release. So I waited a couple more weeks to submit, and I’m glad I did. A lot of features really came together.

During the time of the initial release and the update, a lot has been going on inside work and outside of work, so this has been a lot of midnight oil, really hard to dev during this time and I feel very lucky to have done so much in so small a time despite the obstacles.

Character Customization

 

(Continued)
So, now to talk about some of the major additions!
As you know, I really love to work on RPGs. Just working on the technology itself is fun. Even more fun is when you get the chance to bring in some of your own gameplay design and storytelling into the works. I have had a lot of D&D sessions under my belt as both a player and as a DM. There are a couple of groups which stand out the most to me. One of those is the OakHome D&D campaign I ran for several friends. Some of those characters are honored in the outdoor level. Bargley himself is based on a villain from the original D&D Basic handbook And the basic storyline elements in CastleGuard2 are a predecessor for a much larger RPG named Gryphon, which was begun in the Torque Game Engine and is the next step for the engine I’ve been building here with CastleGuard2.
For these reasons, and for major influencers like HackMaster, Knights of the Dinner Table, and the belly laughing that goes on around a gaming table, the dialog for my RPG games is pretty much always going to be “corny”. I will misspeak, misspell, speak in broken or improper English, all of it for what I imagine to be good effect. It makes me cringe sometimes to do so, but hey.. anything for the art!

Here are some of the major enhancements in this official release, and some notes about how they were created.
NPC Conversation System and Dialog System
All of the NPCs are assigned a dialog tag and initial animation. As well as customization features so they can look different and have different personalities. I began recording voiceovers for some audio greetings too, but ran out of time on this update. I have a large XML file I keep all the dialog in, and when the NPC is interacted with, the dialog tag is looked up in the dialog database. This is modified by any plot increases that have taken place. From all this, a dialog block is pulled up. It includes things like the title on the screen, the button captions, onpress functions and parameters, and of course the dialog itself. It also includes an audio tag for future use. The functions can be anything I can think of, from rewarding an inventory item to setting a quest flag, to adding/removing health, to simple things like forward/back/close the dialog page. The animation the NPC will play when you interact with him is random, but he will also turn to face you, respectfully.

The system is so versatile that I am also using it for help and credits. I can also add images to the screen, but haven’t yet simply because the screen is small.
Because the data is in an external XML file, I can modify it at will and just include it when I go through the production stage to compile a game build.

Character Footsteps
This was something I wanted from the start, but only just got in place. In Torque it can be fairly trivial to do footstep sounds because the model format supports animation triggers. In the engine I am using however, called Shiva, the format is Collada (DAE) which (to my knowledge) doesn’t support animation triggers. An animation trigger is a flag you can set in an animation which the program will fire off when those parts of the animation are hit. This is extremely useful for a couple of things: weapon swinging and footstep sounds. In weapon swinging, you can tell when the weapon is extended furthest from the body and can use that as the signal to perform an attack result. This would let you make sure your damage is synched up with what’s going on the screen. An alternate approach is guessing how long it takes and waiting. The other more visceral reason to use animation triggers is for footsteps. You can tell when a foot is touching the ground, and can therefore do things like leave a footprint decal on the ground, kick up some dust, or play a footstep sound. You can even do things like figure out what kind of surface the player is on so you can play an appropriate sound: water or wood for example.
Like I said, the model format doesn’t use animation triggers so I had to come up with something fast and light that would achieve the same thing. I ended up closely examining the walk animation and making a solid guess at what animation frames the foot is on the ground. I then changed these into percents of the animation: 25% and 75%. Because an animation can play very quickly, this function could be trying to play sounds very quickly, so I had to make sure this wouldn’t cause the device to crash. I also wanted to make sure the sounds made sense and skipped appropriately if the opportunity to play a sound went by. The final result is a simple and appropriate footstep sound which works on the iPhone and seems to match up to the animation. I am not doing anything fancy yet like detecting the material underfoot, or even if the player is on the ground. This means sometimes he is in the air briefly and still playing footstep sounds

Auto Targetting/Enemy Names/Visbility
I am not a big fan of auto targetting in games. But the iPhone is a different beast. I had thought it quite sufficient for people to tap an enemy they want to target, just like you need to click a target in traditional RPGs like WoW. Unfortunately this was a very unpopular assumption. The net effect was that people had no idea how to play. They also didn’t read the instructions. Completely my fault in the end though. So I came up with a system by which the nearest enemy is targeted if you do not already have a target. To actually get this going was more complicated than it sounds. There are a lot of conditions that can muddle the works. What if the nearest enemy is an invisible one? What if they are on the other side of the wall? What if they are 1000 meters away? Calculating all these things, especially something which sounds SIMPLE, like is the enemy visible to the player, was extremely complicated. I rely on a core functionality called raycasting between the enemy and the player to determine visibility. If the ray is not broken by something the player can collide with, I assume the target is a visible one. Then of course the player can collide with himself if you’re not careful, and with things we need to tap on which respond to these invisible rays. Sometimes you’re too close to a wall or a wall is too thin and the ray goes right through the wall without being broken. Sometimes there is a miniscule non visible crack between two walls and the right ray will zip right through there. I am relying more and more on this visibility algorithm though. It’s also used to determine wether or not to show a target’s overhead name and healthbar, as well as figure out if a spawner should spawn another enemy. I need to work more on this algorithm, it’s good enough for now to ship the release.

Enemy Names/Healthbars
Somewhere in the above I mentioned overhead names and healthbars on enemies. This was something really awesome to be able to add, as you don’t need to guess how much damage you are doing to an enemy or if they are close to 0 health. You can see it. This means constantly repositioning the display element, and updating it efficiently when the health changes. You really need to optimize when you’re programming for the iPhone. The iPod touch is so much faster, and the next generation of iPhones will be faster yet, but the 1st and 2nd gen iPhones are really going to run this game slow for now.

Avatar Customization System
This was something I had up my sleeve pretty early on really. It lacked a good interface which worked for the iPhone. It was fun to make though. The engine I am using made it very easy to add things like individual cameras for the different body areas. So you get different camera views for face, beard, and clothes. My son and wife advised me to come up with names for all the options instead of my boring “Hair 1, Hair 2″ list format. So I did. Add in the ability to change your name, save all these options and reset them too, and it amounted to a HUGE but in my opinion AWESOME addition to the game.
Avatar customization is something I love to code, and I even wrote an entire 200 page course on it for the Torque Game Engine.

 

(continued)
Movement Controls and Framerates
I will gladly admit that I really liked the original tilt based move controls in CastleGuard2. I thought they felt natural and responsive. Probably 10 out of 70,000 people agreed with me. Sometimes you can really make a bad guess. This is probably the #1 reason why the pre-release is sporting a 2-star average review. Two Stars. “It hurts Shrek, you cut me real deep.” I’m guessing the other reasons are poor performance on the iPhone device, and lack of tutorial. I addressed these things immediately when feedback began pouring in. One of the non-obvious fixes I did just recently was adjust the tick rate of the game itself. I modified both the minimum frame time and the maximum frame time to smooth out the performance differences between iPhone and iPod touch. This means the framerate won’t go as high as it used to (when those moments are in in play), but it also won’t go as low either. I am still limiting the number of onscreen enemies to 3, so framerates shouldn’t dip anywhere below 10. That’s really low, folks, but it *should be* playable on the iPhone. I had no idea the iPhone was so much slower, and it’s my fault for not borrowing one to test on at first.
Still, I went through all the levels and cut out objects, optimizing draw distances and activation ranges, slashing texture sizes and model qualities, reorganizing bigger levels into multiple smaller levels. Pretty much everything I could think of to increase framerates. It stunk to have to remove some of the cool props and scenery, and I look forward to adding in a graphic quality option that lets those with faster devices get a better visual experience.
I didn’t want to completely lose the cool but expensive weapon trail effect, so I limited it to when the weapon is swinging.
I also am experimenting with different enemy AI setups to try and squeeze more performance out of them. I will also need to find models with lower bone/skeleton complexity.

Sound Effects
In addition to the footstep sounds, I added in world sounds and additional hurt sounds for the player. You can now hear small audio things going around, especially outside, and sometimes your hero will let loose a bloodcurdling scream when he gets hurt or hurt badly. Also a cool sound when he is healed.

This project is now going to branch out into two different games. One of those is an online RPG Combat Game. The other is a much broader RPG Game, with some online elements. This will be the RPG Combat Game plus lots more storyline and content.

Thanks very much for your support and your feedback!
------------------------------

 

Well at least there are touch controls. I really disliked the accelerometer controls before. Plus I shouldn't have to worry about FPS on my iPod Touch 2nd Gen. If the update is smooth it could make this the best 3D rendered RPG style game for this price (*cough* Space Survivor *cough*).

 

Maybe a little, but hey as long as there is touch controls I will be happy. Plus it can't always be perfect. Some may like it, others won't.