A full test group submitted many bugs which needed addressing, and my son and several testers helped me test several online duels to iron out some other miscellaneous bugs and needed features. I submitted the first build of Arcana: Spell Duel to the App. It was a lot of spare time work this summer but it was definitely worth it.
In the next two weeks I’ll be working on a promo vid and figuring out what to do next. I’m glad to have this done, as I’m expecting a new baby any day now!
In the spirit of giving, and of fostering perhaps a community RPG project like what we used to have at www.mydreamrpg.com, I have released the source code of CastleGuard2, my iPhone RPG created with Shiva. It doesn’t contain any of the protected artwork which is licensed to me, but it does maintain referential integrity. I’m releasing the project for a few reasons:
You can find the thread/files here. There is a Personal Learning Edition (free) of Shiva which you can use to figure out if it’s the right tool for you to use to make games with. It uses StonScript, a LUA-like language for coding. I personally think it’s an exceptional product and I look forward to using it as long as I can, or until I need more!
The game previously known as Recombiner has been going by the working title Arcana: Spell Duel. There’s a cuople threads about it over on TouchArcade where I post frequent dev updates. I’ve had some vacationing and a lot in life going on but I found some time to get some playtesting in and some new features added. I’ve finished adding in the replacement player, using my existing customization system and player. I added in new skin color options and all the clothing options for a really wide range of appearances. Though the players ingame aren’t using the custom settings yet 
I’ve also added in a battle scene system and am building some new environments. I am using one large outdoor map right now with several predefined locations for battles for now.
Anyway, the purpose of this album is to show off the new interface (work in progress) and the customization options quickly.
I’m shooting for end of August for submitting to the store. Online battles are working, just a big list left to do and balancing, etc.
Enjoy!
I’ll add some details later 
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.
3 Photos
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:
Needless to say, I am super pysched at what this is going to bring in terms of new features for the games.
Until next time!
Dave
OK, the title has “Data” in it, the rest might be embellishment a bit. The CastleGuard2 update hasn’t been approved yet, and so I still sit excitedly by waiting. And planning the next tactical strike. I love the feeling that I made one of the first 3D iPhone RPG experiences and am really trying to push the envelope going forward in terms of persistence and replayability.
Now that CastleGuard has grown significantly as an engine, it quickly outsized the “inline” methods of virtualizing weapons and the like. Meaning, whereas before I could get away with making functions that switch weapons, and have 12 or so weapons inside the function, it isn’t as efficient as it needs to be and doesn’t scale too well.
Weapons can have effects and modifiers, and all have their own individual stats for things like speed, damage ranges, weapon ranges, and the stance the character is in when the weapon is equipped. The stance is also used to figure out the correct walking animation and attack animation.
The best way to create an engine is to make it content-independent. Use data to drive your gameplay. I’ve already done that with dialogs and quests, now it’s time to do it for everything else. This will make it a lot easier to make massive content changes or additions in the future.
I made a list of all the data files I need to assemble:
Weapons
Armor
Jewelry
Effects (like +1, Flaming, etc)
Spells
Skills
Items
Merchants (describe the things they sell and the prices)
NPCs
Level and Skill progressions
These will just be offline xml files and will make it easier to develop the online portion, as I will just be reading XML generated from PHP which reads the database anyway.
While waiting a few hours for jury duty last week, I also designed a screen model which I think works well for item-based lists, for things like stores, spells, inventories, skills. It is quite a challenge to get right on a tiny little screen!
I checked out Zenonia and while the game is cool story-wise, their GUIs are just insanely hard to use. No fingers are that small….
I have also been thinking about how long I will target for development. A lot factors into that, but I’m sure I need to get it done within 2-3 months, before I get 100% occupied with a new baby in the house. Sometimes development goes quickly and I have a lot done already, but with this many moving parts, debugging and getting it “all right” is going to multiply the effort considerable.
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!
Ninja Rally is a really sweet looking and original title I’ve been working on here at Gamesville since early January. Some people have heard me bandy the name about and asked about it. Well, it’s been rejected from the App Store twice now for some rather small and simple reasons that were easy to address, and we’re awaiting approval once again. Yet excitement has been building, so I thought I’d say a word or ten about it.
I’m really excited about this game for a few reasons:
1) It’s my first TGB title. I’ve been working with Torque for years but never had a good opportunity to use the 2D version, called Torque Game Builder. Although it came with a really large number of gotchas as an early technology, I had source code access and was able to make tons of engine modifications to make all the good stuff happen. This meant I was able to contribute a lot back to the other devs working with this technology and that always makes me feel worthwhile.
2) It’s a multiplayer game! It’s WAN playable and a surprisingly fun head-to-head experience. When I first cranked up the multiplayer with my manager after a few minutes of intense rallying and battling I could feel the adrenaline in my blood. The gameplay really draws you in, quite a feat for a ’simple’ game. Different folks even have different playing styles which totally come through in the gameplay.
3) The artwork and sounds are FANTASTIC! I used all caps there, in case you didn’t notice. My teammates Amber and Ryan cranked out all the art and sound respectively, with Ryan doing GarageBand sessions and recording fierce Ninja yells in secret corners of the building here. Amber brought a very special talent to bear on the Ninja Rally storyline, with obvious results. What made it all so special was in certain moments when we knew we had just the right feeling, and bringing it all together we just got that “wow, that’s just..awesome!” kind of feeling. Not many of those moments come out of an average day job
4) It’s got a good story!! Just when we thought we had the project fleshed out, the Ninja story guru from on high scribed down in stone tablets what was to be the Ninja Rally story mode. We made room for it in the project plan and got ‘er done. After some editing and creating a story engine, the Story Mode added a whole new level to the game and I’m so glad we did it in retrospect.
It was a boatload of work but probably some of the most fun project work I’ve ever done. We are going to wait and see how people accept it, and where it goes. It’s very exciting to do this whole waiting thing, wondering how your game is going to hit the world after putting so much into it. I’ve been through enough death threats and one star reviews with CastleGuard to weather anything, and some people will always hate your work, but I have a special feeling about this game.
We took a few weeks of beta testing and tweaking, picked things apart and put em back together, but it was well worth it, and I feel like we created something wonderful as a ‘game task force’. Because of that, even long after the cries of HYAH! have faded from the halls of glory, I will still see Ninjas rallying in my dreams.
When the durn thing gets approved, I’ll post a link. Until then, check out the awesome NinjaRally.com site!
