I have taken the first few large steps on the road to DangerLands. As usual, distractions rear up and beckon to me. I’m working on some really cool tech now for world building and game editing ingame. I plan on spending 1 month on the tools and let folks begin building things online. These tool are already very powerful, especially the dialog editor. The concept here is that we can make dialogs ingame and attach powerful game commands to the buttons, without having to go code everything manually.
Check these pages for some more info and early vids!
Though.. it’s not *just* iPhone. It’s more accurate to say that it’s a cross-platform MMO, but it FEATURES an iPhone client. Which makes it a front-runner in that arena anyway. Here is the full post, which I broke on Touch Arcade:
This has been an exciting summer! A new baby for me, born on 9/11/09, and the release of my third solo game (Arcana: Spell Duel) on 9/12/09. I’m quite proud of both
It also marks the time when I decide to get a team together to work on a game that we’ve been wanting to make for a long time. The timing is perfect. I’m between updates for Arcana and CastleGuard2. Working alone is great sometimes, but you really miss having some help when companies like Gameloft are cranking out really nice and well-polished titles. My art skills are somewhere between non-existent and horrendous after all, and I’ve had a rough time getting by on my own. It’s time to raise that bar, a thousandfold.
It is therefore my pleasure to announce:
New 3D iPhone MMO in Development
A new MMO with the working title ‘Gryphon’ is currently in development. This MMO is being built from the ground up as a cross-platform MMO. This is not the “text and pictures” style game that is prevalent in the App Store now, but a full 3D real time online game: with everything you would expect from (yesterday’s) and today’s Massively Multiplayer Online games, and more.
massive areas to explore
pvp as well as pvm
quests
immersive and strategic combat
brilliant spells and spell effects
skill-based character system
full array of stats and leveling to create a unique character
online chat and emotes
diverse crafting: perfect for casual play or long term play investment
property ownership
thousands of inventory items
build your own section of the world and influence the main story
unique gameplay elements [B]not found[/B] anywhere else
staged releases, with new features being added with each new release
A key differentiator for Gryphon is that it is being developed from scratch with an iPhone client and casual gameplay in mind. So, while you can play at home on your Mac or PC, you can also play using your iPhone using 3G or WiFi, your iPod Touch using WiFi, or even your favorite web browser! There will be additional platforms developed in the future. This cross-platform design will let you take the game as seriously as you want to, wherever you want to!
The development team is using a rapid prototype and development release cycle which will facilitate an organic growth model in response to user demands and overall story arc vision. This means frequent releases and content updates focusing on key gameplay features in a manageable way, giving the players something new to look forward to each release.
Who is the team behind Gryphon?
They are a motley band of foolhardy gamers and Indie developers who have created a secret club and handshake to do something which moves quickly and sweepingly into your daily life. Small, but powerful. Like Yoda. If forced to answer the question “What is the game going to be like”, they might say something like this: “Our unofficial Gameplay Influences are games like Asheron’s Call and World of Warcraft, and the art team is heavily influenced by brands such as Lego, Dr Seuss, and the Muppets.. which are trademarked and copyrighted of their respective owners, of course.”
What is the Story of Gryphon?
Rumor has it that the design team has accidentally discovered an interdimensional window to a parallel universe and is focused on recording and making drawings of the things they see going on there, which serve as inspiration for the game. There’s no telling when the window will close, so this is a very busy time indeed!
One thing is clear. This story has never been told, and it’s going to take quite some time and many episodes to do it.
You..the player.. will have a part to play in it
Right now we are about at the point where we’re deciding what will go into the initial release and plotting out the map to get to initial release in early November. The World/Story Team and the Art Team are about formed up, and the Development Team is close behind.
I went to bed late last night with visions of sugarplums dancing in my head. I actually wrote that previous blog post from bed, my wife was asking me “what are you doing?” and I told her I just needed to get my thoughts in order. I had great hopes that click-to-move (I’m gonna use the acronym ‘CTM’ for now on) would be a holy grail. The bottom line is that it would save a tremendous amount of network messages that would normally get sent out many times per second, per user. So at the rate of 10 times per second, if you had 20 other people in the scene with you, you would be receiving 200 network/positional updates per second, and sending out 10 messages yourself.
CTM allows me to broadcast the requested target position of the player, and the code will set basically a navigation target marker. Then at your own leisure, you update the position of the target object until it is where it needs to be.
There is already a navigation pathfinding framework in Shiva which I tried to use. I’ve used it before for CastleGuard2, all the monster AI relied on it. Basically you build a level/map, and then you build a path node grid of navigation points. When you want to use it, you pick a target spot, ask the navigation system to tell you what the nearest navigation point is, and the system finds you the shortest path between those two points, using only the navigation grid. Then you move a navigation object along that path over time, and update your player to be near that navigation object to create a nice smooth transition. It works quite well.
Unfortunately it comes with a couple drawbacks. The first drawback is that you do have to build (manually) a navigation map for your entire level. That takes up memory (albeit probably not much) but could potentially be quite painstaking. I plan on having a free-roaming and possibly large game world, and some of it I wanted to procedurally generate. This means I can’t manually build nav meshes for every level.
One of the other drawbacks is the feel of it. As a player, I want precise control, as precise as I can get it. When you use a nav pathfnding system to move a player character, he will always face in the direction of the nearest path marker he is journeying to. However, the path might not be in a straight line, even though there might not be any objects between you and your destination. That’s due to the granularity of the navigation mesh. It’s way too expensive to have navigation nodes everywhere, so you pick a granularity number, say 1 unit, and nodes are placed every 1 unit. However you don’t move (or turn) in values of 1 unit, unless you’re making Frogger. So the effect is crooked paths to represent the shortest point between A and B. This is fine for enemies, as they can use it to avoid obstacles and what have you, but bad for players.
So I took a chance and ditched the navigation pathfinding experiment, and rolled my own. It works in a similar way in that a destination navigation target is set, and a navigation object is used also, which your player object updates itself towards in a smooth manner. The difference is that as soon as you place a new destination, your navigation object orients itself towards that destination object, and then moves FORWARD towards that navigation destination in a smooth manner. It also will continue to point at the destination. The end result is that you turn and point in the direction you wanted to go to, and you walk towards it. Just like you would in real life. This means no strafing possibly (unless I combined the CTM system with a tiny bit of normal multiplayer movement).
I am quite happy with the result, and it feels *great* so far. A heck of a lot less clunky than the FPS style movement or dual sticks that everyone complains about on the iPhone, and always draws comparisons to the latest greatest dual stick mover.
Time to have some breakfast with the family, and then see what’s next
I had rapid success with creating drag and drop inventory this week, so I started in on an online multiplayer framework that would work on the iPhone. Arcana showed me that turn-based is quite doable, but I had a hankering to have more realtime play, mmo style. I had a multiplayer prototype pretty early on this year actually but I wasn’t going to use it soon and I didn’t keep it around.
I’ve also learned a bit more about nuances and timing gotchas that happen on the iPhone.
So I created a timer loop which sends out updates 10 times a second. On the other side, the remote client receives the update and interpolated the physics object attached to the player object and creates a smooth update. I tested it first with two players, then after figuring out how to use the interpolation and physics object to smooth things out, I turned sown the update frequency and tested with four players. Two web browsers, an iPod touch 2g, and my iPhone 3gs. It ran pretty smooth all around, but I have a nagging idea that just won’t go away…
If I were to use click-to-move gameplay, where the player clicks a spot on the ground and then moves towards it, I would *dramatically* cut down the net traffic. I’d also be transmitting rotation, but then the iDevices could handle many more players in a scene. I’m going with a crazy low poly count on the player model: 559 right now. It would be a tremendous competitive advantage if I did something no one else is doing and made it high capacity as well.
The real crucible is that the average gamer likes a certain style of player control. So CTM could be a nasty failure. I need a success. Well, as awkward as it may be, it is a magic dust to the game technology so I am going to begin thinking of it as a gameplay feature. Diablo was a CTM game.
So tomorrow I will prototype that concept and see how it pans out. While using traditonal multiplayer networking means I can’t even come close to the MMO moniker, CTM could very well help that to reality. The big prob with iPhone multiplayer is that it’s hard to find pol to play. Lots of games and casual gameplay needs make multiplayer a flash in the pan. I plan on countering that by going cross platform with the client, allowing web, mac, pc, iPhone. This should help ensure that players will be online to give the persistent world the life it needs.
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!
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!
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.
