I began working on a spell system this past week after many hours of design and planning on my commute. That’s one good thing about a long commute to and from work! I plan to use it in an upcoming CastleGuard2 update as well as a new title.
There was an incredible special effects system written for Torque by Jeff Faust, called ArcaneFX. It is way ahead of its time and gives unbelievable effects power to the programmer. It gave me a slew of art assets to use, and some great design cues for various spell examples.
One of the coolest things about it is the concept of an effects choreographer, which is a type of object which can manage and orchestrate smaller parts of an effect which could result in many many different things. An example of that would be a series of animation sequences and sounds tied together to make up a cutscene sequence. Or, in my case, a sweet and deadly spell system. I was even able to recreate one of ArcaneFX spells, called Flame Broil. This may look like ArcaneFX running in Torque, but it’s not, it’s 100% Shiva, scripted in LUA and running in Dave’s Sweet RPG Engine for the iPhone. Of course I can someday release everything in web, mac, pc, and linux as well.
This also shows the Grog, a new and very meaningful race which will be appearing in the CastleGuard world. Yes, it’s the Torque Orc, with an accumulation of 101 animations and he’s now converted to Collada and fully imported and linked into Shiva I never had a use for him before, but I sure do now!
It does a ton now, driven from an XML data file. In the spell I’ve recreated, the effect consists of:
5 zodiacs, which are rotating textures on the ground, moving at various speeds and radii, and fading in and out at various times.
4 animations, with different timings and animation rates
1 hand constrained particle emitter, to simulate a ball of fire being formed in the hand
6 rotating particle emitters, orbiting the caster at the same radius but different speeds/directions and lifetimes
1 missile, a fireball with particle trail and constrained to the hand of the caster
4 sounds, played at different times
Needless to say, I am super pysched at what this is going to bring in terms of new features for the games.
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.
Without further ado, here are 3 new videos showing some gameplay from the CastleGuard2 official release. They’re at low resolution, so should be easy to view for everyone!
Character Customization
Gameplay Demo
Boss Fight
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.
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!
OK, I admit. I badgered the post title to make it work. It does kind of mean something however.
After weeks of midnight oil burning to get out some major CastleGuard updates, I got it to a point where I was proud of it again. The move controls have been revamped, the combat system optimized, several pages worth of tweaking and bugs ironed out. Then I borrowed an iPhone to test it. To my dismay the framerate was all the way down to the 10-12 fps mark. Really disappointing to me, as the iPod touch I dev on was almost always above 20fps. It’s a verified fact that the Touch has a faster clock speed, but the overhead of running the comm background programs must really take a toll.
Commence chicken sacrificing! I dove down deep into the codebase again with a sharp knife, whittling, slicing, dicing, and generally causing havoc and challenging all that I knew to be good and true. I examined all object visibilities, occlusion culling, activation distances. I snuck in a bunch of “early exit” conditions I had missed previously, which lets a function avoid processing based on certain conditions. I also went through and applied some code optimizations, even some that I knew were going to give back peanuts in terms of processing power. I even spent awhile experimenting with various texture filtering methods and reducing polycount on the walls, which are already low. I do feel like there’s a ton left to optimize, and I am determined to squeeze every ounce of performance I can out of the codebase.
Full 3d game with content is so close to possible on this device, I can feel it. When this update is approved, there’s going to be a lot of folks who love it, and a lot of folks maybe (iPhone users) who hate it. I probably need to make a “performance” setting which shuts off things like torches, furniture, decorations. And make the area sizes even smaller than they are already.
My wife got involved finally too, giving me some helpful suggestions and her opinion on various gameplay elements. I actually incorporated some of those ideas in now, like adding in avatar customization now, though I hadn’t planned on releasing that for awhile. I hope you find that part fun to play with!
There are well over 5000 downloads on CastleGuard2 and it’s been out for one full day now. I have been receiving a good old-fashioned blodging for a couple of major issues in CastleGuard2. One is that the framerates on a lot of devices aren’t good at all. Two is that the control scheme (tilt to turn/move) is leaving a lot of people dizzy and disgusted. So of course I am addressing those things immediately. The first issue, framerates, was a potentially frightening one, as I thought it was the enemies’ AI that was the culprit, and I have already handicapped them quite a bit to keep performance up. But it turned out to be a lot of other optimizations that needed doing, and I haven’t yet needed to touch the enemies’ AI to optimize further. The bottom line is that the framerates are at least doubled, and even the slowest framerate I could bring it to is faster than the normal framerate in the original release. The framerates had felt great to me on my iPod 2G, but when I added an FPS counter in they were actually around 10-12 fps. Now, that’s as low as it gets with a ton going on. Normally it’s a little over 25fps, a very respectable number indeed.
All in all it feels so much smoother.
So, next I will turn to the control scheme and do a couple of things: I will add in a calibration option for the tilting for those who like it (and there are a bunch of you, thanks!) and I’m going to add the directional onscreen controls that most folks are clamoring for.
After that I will be dropping in the story and dialog engine I’ve been working on and get that content going.
I wanted to post quickly to let everyone know that I did get the 1st update out finally… but not as an update, as a new application. It turns out that I submitted the first CastleGuard application right before they added some new requirements, and the unique ID that is once and forever belongs to the first application is not updatable.
My solution is to release CastleGuard2 as a new application. Its gameplay is completely different anyway. It was meant as an update originally however, so I’m going to pre-release it for free. Sometime in May when official release comes it will go up to a normal price. This free period is to be fair to everyone who bought the original and are expecting an update.
If you would like to see what it’s going to be like, check out the CastleGuard2 link at the top of the page! I put up a work in progress version in a web player.
Here are 26 shots from the new update. I am having a bit of trouble submitting the update as the bundle identifier for the original is now an invalid format apparently, I’m trying to work with Apple to get it sorted.
The new update includes a single multiple-area dungeon, 3 new monster and AI types, powerups, doors, ‘flavor text’, and 3 different boss creatures. It took a long time to get an optimization pattern for building a -well -performing dungeon, and I probably still put too much into the areas which might make the game chug a bit sometimes. I’m working on it though, and am going to put a good chunk of time aside in the coming months to make the technology much more robust.
The way I created area transitions means I can add many many content areas without affecting the performance of the game. I will probably scale back the number of active creatures as well to give more room for trap designs I have created. The story/quest engine is designed and roughed in as well.
I’m definitely keying in on the various tricks for performance optimizations while trying to run a nice 3d game on the iPhone. I have a lot to learn yet no doubt. My goal is to make a fun and rewarding short and long-term experience for users while not frustrating them. Into that mix some story telling and vicarious combat experiences, and hopefully you will find that 20 minutes have gone by and you’re still having fun
I will update as to the release situation when I hear back from Apple. Until then, enjoy the gallery!
These are live screenshots from the actual device, so they’re in 480×320 resolution. Keep in mind that when viewing on a large screen they will look pixelly
It’s been an awesome night of coding on the game. I finally hooked up the accelerometer on the iPhone to the turn function, and moved the Forward/Back touch areas to the convenient right side, getting rid of strafe for now. I also added in a pan cam up/down touch area, because the outdoor scenes (there are 3 of them in production) are pretty to look at. I linked up zoning triggers so you can jump from scene to scene.
I also had a lot of fun working on the first dungeon, and added in a rudimentary dialog/story/quest system that now needs lots and lots of data. I kind of overshot on a few areas for the first update unfortunately. I will end up scaling back to one dungeon and one outdoor area probably so I can get this update out the door.
During my lunch break yesterday I worked on a basic avatar customization system. It will probably make it into update 2.
One of the other more interesting things I’ve begun to look at is multiplayer. It won’t be for a few months yet, but this will definitely grow into a multiplayer technology.
I’ve finally nailed down the new camera code! It took a while (I knew it would). The purpose of it is to make sure the camera doesn’t get behind a wall as the player moves around in tight quarters. I also have created the spawn/trigger functionality needed to do things like monster spawns/respawns. I am planning on using that functionality for other things too, like traps and special effects triggered in an area.
Yesterday during lunch I rewrote the AI’s main routines to highly optimize them and make them easier to expand. This should decrease the load on the processor and let me fit more in. Good for framerates! I did notice that there is a tiny hiccup/jump when a group of monsters spawns in. It can’t be helped; introducing a new object into the world is an intensive process. I can smooth it out by introducing a tiny delay between spawns though. Shouldn’t be noticable to the user then, and will smooth out the jump.
For art side, I dug up a TON of artwork we had from way back in the Torque MMOKIT days, so the user interface will be getting beefed up in this update. With the camera and moving code out of the way, I can get to the fun stuff of flushing out the level and adding in some extra functionality. I have already started decorating with torches and some wall decorations, the art from the MMOKIT should help in that department. I plan on working on it over the weekend and am targetting next Monday or Tuesday to submit the update.
Day 4 of CastleGuard being in the wild. It’s selling between 50 and 100 copies a day which is pretty cool. Some folks finally started reviewing and posting stars, and the results are interesting. No 3 star reviews, folks either love it or hate it. I imagine the ones who hate it didn’t really read the description, but that will change soon once Update 1 and more are out.
I’ve been working hard on update 1 in my spare time (which is pretty little right now as I prepare for the NinjaRally iPhone game release) but some major milestones hit already.
I got the skeletons in as a new enemy type and I have the move/camera code pretty close to where I want it to be. Some of the mission types will preserve the ‘locked in place’ style gameplay at times, in honor of the original concept and as part of the storyline. this will be the ‘Defend’ mission styles, you will walk aronud for a bit until you trigger the battle, then get locked into place for the defense battle.
The last part will be deciding on a good control scheme for it, and minimize the presence of onscreen GUI for moving around. Here is a quick pic and for the more bandwidth savvy, a video! I apologize for this video quality, running in a virtual machine with a vid cap program, I’m surprised it capped at all. I’ll get a better quality one soon once I have more features in.
I posted a demo video of the CastleGuard game I whipped up this week in the CastleGuard link above. Let me know what you think! This game was submitted to the iTunes App Store on Friday, I’m busy testing new features tonight. I’ve got a few different types of elemental weapons ready to go, and a Diablo-style camera coded up too. The gameplay is extremely simple intentionally right now, as this is my first iTunes submission and one of its main functions is to test the waters and learn the ropes.
However… I love me some game coding… and I’ve got plans to add lots of functionality into this codebase. First up tonight will be some bug fixes (there are 2 known bugs) and create difficulty levels. Losing an hour’s sleep though, so that might be it for tonight.
I never had a use for him before, but I sure do now!
