Torque 2 Game Engine Enters "Transparent" Development
Stephen Zepp of GarageGames posted today about "Torque 2" entering "heavy development." In addition, they are attempting "Transparent Development" - which is to say they will be making the development process visible to the community, and inviting the community's feedback during development.

Sorta like what I'm doing with Frayed Knights. Only hopefully much better.

What's this mean to indies using various flavors of Torque? Well, possibly a lot, but not immediately, except for the chance to have more active participation and visibility in the evolution of the new engine.

For one thing - their "hit list" addresses key issues that have been major pains to developers. Mainly, it's breaking down the monolithic structure of the game engine into modularized components. Since I've learned that too often making "one little change" in Torque involves eight different changes across four different files (pretty much "by Braille," since there's very little documentation on that code), this sounds like a good idea to me.

The new engine will incorporate both 2D and 3D technologies similar to what is currently in TGB and TGE-A, but will not be backwardly compatible with the previous engines. It will use "Poly Soup" collision handling by default, which means the old CSG-style / BSP-based interiors may finally go away. It is intended to be easier to "plug in" major systems (like Python or LUA instead of TorqueScript for scripting, Zepp suggests) with the new modular architecture.

But aside from this, a lot is up in the air. The "transparent" process means there'll be a lot of things discussed in the "transparent development" community, considered, and maybe even attempted that don't make it into the ultimate 1.0 release of the engine.

TGE, TGB, and TGE-A are going to be "sunset" at some point after Torque 2's release (once it has been given enough time to mature), and details are fuzzy (and likely not determined yet). But the post strongly indicates that any project currently in development - or entering development in the next 6-9 months - should use existing technology. Torque-X is going to remain an independent product and will not be affected by Torque-2's development.

GarageGames, not-so-newly purchased by IAC, now has the funding and manpower now to make this happen - here's hoping for some good stuff.

Labels: programming, Torque

- posted by The Rampant Coyote @ 7:13 PM (Permalink) 12 comments links to this post

 
Torque for the Wii!
The Torque Game Engine has now been adapted to work on the Wii.

The Escapist has the news.

That's the second current-gen console (after the XBox 360) for Torque. GarageGames continues to concentrate on being the "budget engine" of choice for multiple platforms.

According to the quote by Randy Angle of Pronto Games (the folks who ported the engine to the Wii and are developing a Wii game with the engine), "We chose to develop The Destiny of Zorro with the Torque Game Engine because of its proven reliability and our developers' familiarity with it" (emphasis mine). This sounds like an interesting (perhaps accidental?) long-term strategy for GarageGames. They offer their game engine at a price that makes it easily accessible by any fourteen-year-old with lawn-mowing money. Those who actually manage to succeed at it and who move on to bigger, more professional ventures and take their Torque preference with them. Are we going to see a "next generation" of higher-end commercial studios using Torque?

Labels: Torque

- posted by The Rampant Coyote @ 9:32 AM (Permalink) 2 comments links to this post

 
Torque Game Builder 1.5 Now Available
The long-awaited version 1.5 of Torque Game Builder (formerly Torque 2D), GarageGames' 2D game engine, is now available. For details, take a peek at this announcement:

What's New with TGB 1.5 (Include bug-fix list)

The biggest changes seem to be in the addition of Behaviors for objects. This is actually pretty dang cool. This provides an extensible library of behaviors - responses to game and input events - that can be attached to any object. For example, there's a behavior to make a UI object grow when the mouse hovers over it, and another behavior to make the object respond to Asteroids-style controls.

For a programmer-type guy like me, this may not seem like a big deal. But for game developers with less programming experience, this could be a very handy thing. The behaviors allow a lot of basic game functionality to be developed without the need to write any code. I predict lots of old arcade-game clones appearing out of the community in the next few months. This is also useful in a team situation. The programmer can create some more game-specific behaviors, and pass it off to a designer and let the designer play with the logic using a simple GUI interface from that point on. Who knows? New behaviors may also be packaged into content packs (yay! We programmers can contribute!) to further extend the "out-of-the-box" standard game types available for rapid development.

The behaviors aren't going to do away with the need for programmers writing plenty of game-specific code, but it may make prototyping much easier (and give new game developers a little more to get started with).

They've also done some nice ease-of-development stuff like allowing the game directory to be ANYWHERE instead of off of the TGB install directory, and a reduced (compressed?) executable size. There are also the usual array of bug-fixes (no word on whether some of the video fixes required by casual portals of TGB-created game made it in).

While TGB had the usual issues on release, it seems to be rapidly growing into a mature (and very useable) product. While arguments still abound concerning its ease-of-use and other issues, it seems to be evolving nicely into a powerful game development tool.

(Vaguely) related doofiness:
* Torque 2D Game Builder Quick Review
* TGE Plus: Two Game Engines In One!
* Forrest Gump Meets the Avatar of Virtue
.

Labels: programming, Torque

- posted by The Rampant Coyote @ 5:23 AM (Permalink) 0 comments links to this post

 
Playing With Torque Constructor: A Quick Take on GarageGames' New Game Development Tool
Torque Constructor was launched to the public a few hours earlier than the previously announced April 9th release date. This tool is free to all licensees of the Torque Game Engine, or Torque Game Engine Advanced. (CORRECTION: It is apparently free to all those with a garagegames.com account, not just those with a Torque engine license). While it is intended as a tool for Torque, it can save models in the .map format common to many game engines.

Background
Now, my own experience with other Constuctive Solid Geometry (CSG) editors has been limited. I've used QuArK, a variant of WorldGen (I think that was the name) that shipped with Vampire the Masquerade: Redemption, and UnrealEd. And now, I've gotten a couple of hours of playing around with Constructor under my belt. Hardly enough to render a verdict - especially as I am NOT what you'd call a "power user" of any of these tools. I'm still pretty much a beginner, but that never got me to shut up about a subject before, so why start now? So I thought I'd share my experiences.

I have REALLY been looking forward to Constructor. As I've said before my experience with QuArK (Quake Army Knife) has been troublesome. I feel like I've made some level of peace with the editor, but it's strictly a relationship of convenience. I'm not a power-user of that tool, so I've no doubt I've been missing some major conveniences in that package out of sheer ignorance. But I've put hours somewhere in the mid-double-digits into the tool and used it in practice to create real (though not particularly masterful or pretty) levels for Apocalypse Cow.

QuArK is really sharp and useful and capable in some areas, and annoyingly lacking and stupid in others. The interface has always been a little bit clumsy and ... klugey... to me. It might be my ignorance, but managing textures was always a pain in QuArK. And, finally, there was the little matter of setting it up for use with Torque whenever you upgraded to a new version, making sure all the export paths were set properly, and... ugh. And then there were the bugs. The really nasty, I-just-munged-whole-level-lets-restart-without-saving type bugs*. I was never sure if they were because I was doing something wrong, or if it was just one of those issues you just had to learn to avoid.

Torque Constructor: The Good
By comparison, Constructor feels like it has a much more polished interface (I hesitate to call it intuitive... there really is no such thing when dealing with this kind of tool). It is a little less bewildering to a beginner, I think. It's far easier to get into it and start making useful stuff, with a more gentle learning curve. With only about two or three hours of usage, I already felt competent enough to do everything I could do in QuArK (plus a bit more). Of course, it's already set up for Torque. Exporting a DIF file (Torque's proprietary format) is naturally a piece of cake. Constructor allows you to save files in both .MAP format (the text-format standard developed by id Software, used by many similar editors), as well as a new "CSX" format.


I really like the "Free Cam" mode that allows you to fly your camera around the model very freely. The UI layout is also very flexible and easy to configure. While I haven't played with it, Constructor also has the Torque Lighting System built into it, allowing you to see how your creation will look when fully and properly lit. Some really minor but appreciated elements include a grid size scaled more for Torque-sized objects (approximately 2.5 units for the default humanoid character), and the fact that upon loading a large map file, the camera automatically zooms out to encompass the entire level. Small conveniences, but nice. I've got some gargantuan interior levels in Apocalypse Cow, and when I brought them into Torque Constructor for the first time, except for some missing textures I had to correct, they acted as if they belonged there.

Another great option is the ability to bring in Torque models (DTS objects) as reference objects to compare scale.

Constructor also offers several very nice ways of manipulating, slicing, and dicing a brush. From standard CSG subtraction, and making hollow (easily enough done in QuArK as well), there's also the ability to rotate brushes with a fine level of control (down to actually inputting the exact positions and rotation values by hand). Then there's the knife tool, the slice tool, and a clipping tool. Since the knife is one of my most-used tools in Blender, I was pretty excited about this one. I expect these to be pretty handy when developing cave-like levels or levels with more organic topography.

Duplication of brushes is easily supported. Creating a spiral staircase is apparently a snap. You can change a particular brush from being a structural element to a detail brush, or collision volume, portal, trigger, or some other type of object by simply clicking a radio button in its properties. Basic Torque entities are supported, including lights, paths, and mirrored surfaces (though that's not entirely functional yet - see below). There are also things like custom workplanes, that allow you to work off-axis, and little convenient tools like automatically dropping the brush (or even a vertex) to the ground.

I haven't touched it yet, but Constructor - as a tool built using Torque - fully supports TorqueScript plug-ins. Adding to the prefab library is also practically trivial. I imagine that within a few weeks, there will be a ton of community-driven support for these features. I understand that there's built-in concavity detection as well, to make finding of bugs a lot easier.

Torque Constructor: The ... Different
Constructor has its own quirks. For example, creating a new brush is a two-step process. First there's "virtually" creating the brush, by "Activating" a primitive. In this state, much about its core geometry can be changed directly (such as, for a cylinder, how many sides it has, or the beveling on a cube). Once satisfied with the brush (or the cloning parameters), you "make" the brush, and it goes from being a virtual brush to a real, in-game brush. At that point, some features of editing it becomes a little less flexible, though you then have tighter control over, say, the actual vertices. . This can be done deliberately by pressing the "Make" or "Make and Continue" buttons, or it may happen if you accidentally click somewhere else in the scene.
Torque Constructor: The Not-So Good
The documentation on Constructor is fairly skeletal at this point, though that will only improve over time. In return, however, we're getting a lot of time from the developers during this first week directly in the forums.

Constructor has some problems with its initial release, which is unfortunate, though not unexpected.

First of all, portals, zones, and mirrors are not scheduled to be supported until version 1.0.1. If you are just doing small buildings, and don't care if (for now) the interiors are lit by sunlight and the outside ambient light, that may not be such a big deal. But if you are doing big larger, Quake-style interior levels mixed with outdoor terrain, this means you have to save your file as a .MAP file, and then bring it back into the CSG modeler you've already been using, and then export it to a DIF file from there. That's not a crippling step - I imagine I will be doing most of my principle modeling in Constructor for here on out, but it's a painful extra step I'd rather not have to deal with.

Another problem is that you cannot rename brushes, or put them in groups like you can in, say, QuArK. Now, you can group them into selection sets --- but that only gets saved out in the .CSX files, not .MAP files. Again, not a big deal, but since I'm having to save these things as .MAP files anyway to get QuArK to export them with portalling information, that's Yet Another Step.

Texture management is pretty straightforward, with a lot of great tools for manipulating the texture coordinates (including some automated UV grids), save one major one - the ability to use the mouse or keyboard to scroll around the texture coordinates directly on a face. This is a real time-saver when trying to line up textures on adjacent brush faces. Trying to fine-tune this by hand was a real pain. I tried using the texture unification, which supposedly makes this a lot easier, but it didn't work well for me. More experimentation will be required here.

There are a lot of other little conveniences that are common enough that they are missed in this package. The lack of automated "snap-to-grid" functionality on vertices, for example (though the ease of manually edit the coordinates directly makes up for it, for me). I also couldn't directly select occluded objects. In QuArK, repeated clicking in the same area would cycle through all brushes under the cursor. In Constructor, as far as I can tell, it involves either selecting it via the perspective view by moving the camera close to it (which is pretty convenient to do, really, thanks to the camera control capability), or hiding all the occluding brushes. Again, not a big deal, but it would be a time saver.

And as usual with a 1.0 release, there are a number of small bugs, performance issues, and the occasional crash that users are discovering. Trying use the area-select tool on the cathedral caused Constructor to hang on me on one system. The cathedral example provided with Constructor is one such example - it's a really big, resource-hoggy extreme, and people are finding a number of issues with it on various systems.

Torque Constructor: Preliminary Verdict
Three hours or so with the tool is hardly enough to say anything definitive about the tool. But I've enjoyed playing with it, and it seems to give me almost all the functionality I've come to depend on in other BSP-style level-building tools. Unfortunately it may be a couple of revisions before I blow QuArK off my system entirely, as there are still some things which it does better than Constructor (or does AT ALL that Constructor doesn't). And it's not a bad tool. But I am going to start moving all of my primary level-building development over to Constructor effective immediately - even in that short time, it's become clear that its easier to use.

At least for me, the non-power user who only pretends to know what he's doing.

But I will appeal to a more experienced authority on this. In the few days Constructor has been out, Adam Wilson managed to figure it out and posted this picture of a church he built with the tool:

He offered no word on how long that took him, and I understand the interior is unfinished. But I'm gonna call Constructor "Very Promising" at this point.

Now I just have to get back to coding instead of playing with it...


* UPDATE (7/1/2007) - I was contacted this morning by DanielPharos, currently on the QuArK development team. The latest version I worked with was 6.5 alpha (and much of my experience was with prior versions.) He told me that since QuArK 6.5.0 Beta, they have made great strides in fixing memory leaks and silent access violations. According to him, "I know the older versions of QuArK are really crashy, but in my opinion we've done a major improvement with this new version." Definitely good news!


(Vaguely) related stuff:
* Torque Modeling Tool Available Free Next Week
* Raising a Barn
* A Metric for Scoping Games?
.

Labels: game art, Torque

- posted by The Rampant Coyote @ 7:00 AM (Permalink) 11 comments links to this post

 
Torque Modeling Tool Available FREE Next Week
Jussincase you are all ready to take the plunge and create a prize-winning RPG... here's something to help.

GarageGames just announced that their long-awaited Torque Constructor will be available at the beginning of next week. Pricing will be something to everyone's liking... they will be offering the product as a free download.

Torque Constructor is a brush-based CSG (Constructive Solid Geometry) interior-level design tool, comparable (we believe) to tools like the Quake Army Knife (QuArK), Valve's Hammer, or 3D World Studio. The advantage for Torque developers is that it is written in Torque itself, giving more of a "What You See Is What You Get" (WYSIWYG) experience, along with better support for many of Torque's unique features. In theory, it should be a lot easier to work with, should really improve the art pipeline for Torque, and has been developed to appeal to users conventional 3D modeling tools like 3D Studio Max.

And it works on the Mac.

Not that Torque Constructor is supposed to replace high-end modeling packages... it is exclusively (AFAICT) for doing CSG-based objects... read "interiors" for Torque. Quake-style levels. Dungeons. Taverns. Stuff like that, where complex collision detection and rendering management must be optimized.

Why free? Tools have been a shortcoming in the Torque Game Engine for years. They've been reliant upon third-party tools (and upon the community providing exporters for the third-party tools) for a very long time, and it hurts when they get compared to some of the other 3D game engines out there. GarageGames is pretty frank about the rationale on the product page: "Torque Constructor improves TGE and TGEA in an area which has been in need of improvement for some time: the art pipeline. We recognize that, and are making Constructor free not only to thank those of you who have supported GarageGames and the Torque Technologies for the past seven years, but also to increase the value of our 3D engines for new users. Hopefully, releasing Constructor for free will encourage more artists to consider Torque a viable and attractive engine to create art for."

Well, here's hoping it rocks. I've spent some time with QuArK --- not enough to come to love it, but enough to at least come to an uneasy truce where I agree not to swear at it too much and it agrees not to eat my maps very often. I think this might be a perfect time for an amicable departure.

Labels: game art, Torque

- posted by The Rampant Coyote @ 9:17 AM (Permalink) 5 comments links to this post

 
$10,000 Game-In-A-Year Contest
Well. The indie game world just keeps heating up. A new contest geared towards indie game developers (particularly RPG and MMO developers) has been announced - this one with a $10,000 grand prize!

MyDreamRPG.com is running an "Dream Game in a year" contest that started yesterday. In spite of the odd contest start date, it's apparently no April Fool's Joke. The idea is to create an RPG in one year (actually 13 months, according to the contest rules).

The rules seem a little fuzzy, but also very broad and inclusive (IMO, overly so) --- with one major, telling exception: The game you make must be based on one of the four Torque game engines (the original TGE, the TGB 2D game engine, the new "TGEA" advanced-technology engine, or the XNA-based Torque-X).

What's very curious about this contest is the judging criteria. Apparently, its going to be based more on the actual development process than on your final game quality. While the final criteria haven't yet been announced (those have been promised to be announced in 2 weeks) - but Dave Young has provided a post which gives some idea of what they are going for. According to him, "We are going with a point based system this time around, with points being awarded for the completion of various milestone tasks. The idea behind this is that the contest is covering the whole game making process, and not just the final result. In the end, the point totals will determine the winners."

This makes me a little leery, as in his post he mentions things like "backing up smacktalk" (so you have to smacktalk to get those points?), adherance to design (You'd better make sure your design is perfect when you start, I guess, or they'll dock you for changes), and update blogs on the GarageGames site.

As for me, I don't think the timing could have been more perfect. I had already planned on beginning full production of the RPG this month, regardless of the status of Apocalypse Cow. I might be doing double-duty a little bit halfway into the month, but I'm finally seeing the light at the end of the tunnel for Apocalypse Cow. If I enter the contest, I'll have to spend at least two weeks pulling my scattered notes together into an actual design document anyway. And apparently I have to do some things to increase my visibility.

I really don't know if I have a prayer of finishing the RPG by the end of April 2008. But I've got nothing to lose by trying, right? After all, I've created a (lame) RPG in only a week, before, without any game engine or commercial tools at all. A year, plus a budget, plus a game engine... that all sounds like LUXURY.

So - if you were mulling over whether or not to take the plunge -- if you've been talking for YEARS about how you would make an RPG that was so much better than anything else out there.... well, now is your chance. There's a $10G reward for doing it, and apparently handling the production in a professional manner and hitting your deadlines. And whether you win a prize or not - the prizes are only the beginning. You'll have a (hopefully) sellable product at the end of the process, not to mention a ton of experience, your own IP, and... well, something worth MAJOR bragging rights.

If you have NEVER created a commercial game before, I strongly recommend taking a look at Torque Game Builder. It's far easier to use and learn than the 3D technology. If you have any doubts as to whether a 2D-based RPG is commercially viable, I invite you to take a look at Aveyond and Cute Knight - both are based on 2D gaming technology, and from what I have heard, both of them made some pretty serious money last year --- and continue to do so. Or take a look at GameTunnel's 2006 RPG of the year, FastCrawl. Which is also apparently selling pretty well. And all three are a heck of a lot of fun, to boot. There's still a lot of games waiting to be made that aren't dependent on the latest graphics processors.

And hey, I think the time is right for an Ultima VII-esque indie 2D RPG! Somebody get to it! I'll buy it!

Opportunity is staring you in the face.
[F]ight, [R]un, [T]alk, or [C]ast Spell?


UPDATE: While the organizing website is MyDreamRPG, and the community is focused on RPGs, it should be noted here (something that I overlooked, shame on me) that they have very pointedly avoided restricting game entries to Roleplaying Games - even calling it a "Dream Game" contest. So if you are starting ANY kind of Torque game project between now and the end of June, and you expect to be completed by April 2008, you've probably got nothing to lose by entering the contest.

(Vaguely) related shooting the breeze:
* Torque 2D Game Builder Quick Review
* Give 2D a Chance!
* RPG Design: The "Brute Force" Problem
* Interview With Amanda Fitch, Indie RPG Developer (Creator of Aveyond)
* Interview With Georgina Bensley, Creator of the Indie RPG Cute Knight
* Torque 1.5 and a Torque Wish-List
* Forrest Gump Meets the Avatar of Virtue
* How To Get Me To Buy Your Indie RPG
.

Labels: Frayed Knights, productivity, Roleplaying Games, Torque

- posted by The Rampant Coyote @ 7:50 AM (Permalink) 4 comments links to this post

 
Programming Tip: Comment First
Here's a little programming tip that helps me write better code... when I remember to do it. I don't have a really good name for it. I'll just call it the "Comment First" technique for now. I find this trick helps me focus on programming tasks better, helps me stay on target when I'm interrupted, and provides me with nicely commented code.

The technique is simple: When I create a function / method / whatever, I create a stub, and I write the details of the function implementation in plain English inside the stub. (I suppose if English isn't your primary language, another language of choice would suffice. I dunno, I haven't tried.) I format the description as comments, and I try to break them into steps with whitespace between them (blame my learning procedural programming back in the early 80's).

This is sort of like writing pseudocode, which is one of those almost-perfectly-useless things they taught me in college. I never really understood the purpose of using pseudocode outside the language-agnostic classroom. Unlike pseudocode, what I'm talking about is not writing anything that resembles machine-readable instructions. This is purely human-oriented instructions to yourself on how you are implementing the function.

For example, here's a simple function I was working on tonight. This is nothing more exciting than implementing queue behavior in TorqueScript:

function WBQueue::Pop(%this)
{
// Is the list empty? If so, quit.

// Grab the top element in the queue.

// Does the first element have a successor? If so, point the Qeue to this second element.
// Otherwise, set the Queue it to NULL (0).

// Return the original top element

}

The first benefit I gain from doing it this way is that it forces me to analyze the problem from a higher level before I start coding. For example, this code (with some expansion to functionality) was being used in tonight's project to keep track of a scrolling, ordered selection of graphics objects. I was going to implement it with an array. As I thought through it, I realized that it was simple queue behavior. As soon as I think queues, I think "linked list." I'd never implemented a linked list in TorqueScript before, but as I thought about I imagined it would be very easy. And much cleaner than the array approach.

Once the instructions are written out this way, writing the code itself is almost trivial. At this point, I can put my brain on auto-pilot and code away. A side benefit is that if I'm interrupted, it's easier to eyeball what I was doing when I left off, and to pick it back up again.

Another advantage is that, when I am done, those little instructions to myself remain as comments for my code. When I come back to it six months and try to figure out what the heck I was thinking when I wrote the code, I'll take a look at the comments and realize I wasn't such an idiot after all. That does wonders for my self-esteem.

So there you go. Nothing rocket-science-y about it, but I thought I'd offer it here as a suggestion to any other code monkeys reading this.


(Vaguely) related items of questionable value
* Biting the Silver Bullet
* The Joy of Debugging
* Fitting Game Development Into a Full-Time Schedule
* Fighting Procrastination: The Local Maxima Problem

Labels: productivity, programming, Torque

- posted by The Rampant Coyote @ 8:12 AM (Permalink) 17 comments links to this post

 
Interview With Amanda Fitch, Indie RPG and Casual Game Designer
This month, I interviewed Amanda Fitch, the author of the hit indie RPG, Aveyond, and founder / owner of Amaranth Games.

Aveyond (now re-christened "Aveyond I: Rhen's Quest") appeared at the beginning of the year with little fanfare (at least from what I could tell), but found itself popular with both fans of “old-school” console role-playing games of the Super Nintendo era, but also with a brand new audience. In particular, female gamers of all ages have become involved in the story of Rhen, a young farm girl with a mysterious past and a fateful destiny. Because of its success amongst "casual" gamers, this fantasy RPG has managed to occupy top-ten positions for several weeks on major casual portals, something normally reserved for match-three style puzzle games like Bejewelled.

I asked Amanda to share some of her thoughts on indie game design and development, how she got involved in the business, and the two new games that are currently under development. In particular, I got some tidbits about the soon-to-be-released Grimm’s Hatchery, a casual game that may appeal to fans of Aveyond, and the upcoming sequel to Aveyond, entitled Aveyond II: Ean’s Quest.


---== The Past ==---

Rampant Coyote: So how did you end up becoming an indie game developer? And why Role-Playing Games (RPGs)?

Amanda: I wanted to play a game like Kings Quest VI, but I found out that game companies weren't making these sorts of games anymore. I rolled up my sleeves and decided to make the game that I wanted to play. After I finished my first game, Gaea Fallen, I wanted to play an RPG like Final Fantasy VI, but alas, I had the same problem. No one seemed to be making them anymore. So I made Ahriman's Prophecy. Both games were freeware and Ahriman's Prophecy was popular enough for me to consider making games for a living.


Rampant Coyote: Game development is a fairly male-dominated industry. Has that been an issue with you at all as an active member of the indie game development community? Or have you found it advantageous to bring a different perspective or stand out as one of the few female indie game developers? Or does it even matter?

Amanda: The guys have been really cool and very supportive. I do think that I tend to look at games at a different angle than most of them. I look at the story, art, and music first, and then worry about the underbelly of whatever I'm making. I don't care if the ground shakes when my characters jumps up or down; I'm much more interested in their social interactions with each other.


Rampant Coyote: What games have you played that you would consider your biggest influences, if any?

Amanda: Kings Quest and Final Fantasy are my hands-down favorites.


Rampant Coyote: Ahriman's Prophecy was your first role-playing game, to my knowledge. At least the first one you finished and released to the public. In many ways, it sounds like it was practice or a "dry run" for Aveyond. What sort of lessons did Ahriman's Prophecy teach you?
Amanda: I used Ahriman's Prophecy to learn how to present a game to the public and market. I practiced uploading it to sites, and learned a lot about software submission. I also created two versions. The second one was much better than the first.


Rampant Coyote: What did you change in the second version of Ahriman's Prophecy to make it better?

Amanada: I recreated the battle system, all of the menus, and made much better maps.


Rampant Coyote: How much time did it take to complete Ahriman's Prophecy? How about Aveyond?

Amanda: Ahriman's Prophecy took 1 year and Aveyond took 1 1/2 years.

Rampant Coyote: Aveyond was your first commercial game. I'm not privy to your sales numbers, but by most indicators you really hit one out of the park on your first try. Aveyond has not only made it onto several major portals, but has also spent some significant time on their top-ten lists - a place usually held by match-three style games. You have a large number of affiliates, and a healthy community at your site. To what do you attribute your success, and what is it going to take to maintain it?

Amanda: Lots of marketing, a good, long story, and a niche with no competition. I offered something different and it made a splash. Now, I need to figure out how to turn a splash into a tidal wave. :D

Rampant Coyote: Aveyond has been described as a "casual RPG." Was that your intention when you started working on it, or did it just evolve that way?

Amanda: When I started working on it, I didn't know that the indie game market had fragmented into casual and non-casual. Most of the casual games looked cute and light-hearted, so I figured Aveyond would fit right in.


Rampant Coyote: Now that Aveyond has been out for a year or so, what sort of lessons are you taking from it to apply to future games? Is there anything you wish you'd done differently?

Amanda: I wish I had marketed earlier and not made so many changes later on. I was constantly updating the game from January to July and some updates were drastic. In the future, I'm only going to make bug fixes to games that I've already released. If new features are added, they will be part of a goodie pack that players can download from my site. I also didn't have a professional logo for the game until April. I should have done that before the game ever went live.


Rampant Coyote: You've used some pretty high-end toolkits for creating your games - specifically RPG Maker for your two RPGs. Some people get a little funny about that. On the one hand, some people treat it as if it's somehow cheating - that it is both overly constricting and somehow "too easy." Yet there are very few finished games out there using these engines, let alone polished, commercial-quality games of the quality and scope of Aveyond. So what does it really take to create a polished, commercial-quality game using a higher-level engine? If it's much harder than it sounds, is a higher-level engine even useful?

Amanda: I knew that when I released Aveyond that I was stepping into the briar patch. I was very worried about how the development community would feel about my approach. I repeated to myself over and over again that my goal was not to please developers, but to please players.

I also wanted to break the ice and bring attention to Game Creation Systems. I don't think they are The wave of the future, but I think they are A wave in the future. If game creation systems continue to gain popularity, this could be a bit threatening to some developers who like to program everything from the ground up. It would be a bummer to find out that the artist next door made the same match-3 that you did in a fraction of the time with better art, eh?

Actually, there are loads of games that have been completed with Game Creation Systems! The problem is that most of these game makers only show off the games on freeware sites (Game Hippo) or in the communities devoted to the Game Creation Systems. For example, if you go to the Adventure Game Studio site, you will see that there is a huge list of finished games.

Many Game Creation Systems stink, and you will probably never see anything completed with them. The easiest way to find out if a Game Creation System is good is to check out its community. RPG Maker XP, Game Maker, Adventure Game Studio have huge active communities. It's a shame that most of the people who have created amazing games with these systems are afraid to sell what they make or step forward. This is changing, however. In fact, a commercial game was just finished with Adventure Game Studio, and the second indie shareware game is on the way. I also know that indie developers have made shareware games with Game Maker. Too cool!

My guestimate is that 97% of projects never make it to completion with the good Game Creation Systems. This may sound alarming, but it isn't since 97% of all indie game projects fail anyways.

Hey, here's a fun Q&A:

Q. What hugely popular commercial RPG series was build with a 3D game
creation system?
A. Elder Scrolls!

Q. What is the name of this game creation system?
A. Gambryo!

Q. How much is Gambryo?
A. More than most of use make in two years!


Rampant Coyote: Are there any little secrets in Aveyond that most people never discover that you'd like to share?

Amanda: The cash cow, secret portal stones, and lots of other hidden goodies that players probably won't find unless they go to Amaranth Games and find them in the section called “Goodies.”


---== The Present ==---

Rampant Coyote: So, tell us about your next game! Don't spare the gory details!

Amanda: The next game is called Grimm's Hatchery, and it involves caring, breeding, and selling of magical pets. This isn't an RPG, but the game takes place in Candar, a village in the Aveyond universe. I'm also working on Aveyond II: Ean's Quest, which I seriously think is going to blow Aveyond I: Rhen's Quest away.


Rampant Coyote: With the success of Aveyond, and players hungry for more, why did you decide to make a casual game before moving on to the next RPG of the series?

Amanda: I needed a break from RPGs, I wanted to work on a short 5-month project, and I wanted to draw more casual gamers into my world of Aveyond. The conversion rate for Aveyond is very high, and I think a lot of players haven't played this sort of game because it is completely new to them. I hope that Grimm's Hatchery will help me convert more of these players. I want them to fall in love with the characters in Grimm's Hatchery (a traditional casual game), and feel brave enough to try out Aveyond II so that they can experience their favorite characters again.


Rampant Coyote: Do you think the new game will appeal to fans of Aveyond?

Amanda: Oh yes! It's just a bit lighter than Aveyond. There are lots of quests around the village, so there's quite a bit to do besides raising pets and chasing off monsters. I think Adventure lovers are especially going to love this game. Like King's Quest and Monkey Island, each area has a beautifully rendered 2D background, and you can use your mouse to explore each area in the village, just like you would in your typical adventure game.


Rampant Coyote: When should we expect to be able to play the new game?

Amanda: Grimm's Hatchery will be released to the players on my site around December 15th and to the rest of the world on January 11th. Aveyond II: Ean's Quest will be released next September.


Rampant Coyote: It sounds like the original Aveyond is getting a name change. Sort of like how Raiders of the Lost Ark is now "Indiana Jones and the Raiders of the Lost Ark." Do you have plans to re-release it with the name change?

Amanda: Yep, I've already re-released it on my site. I figured that I needed a way for people to distinguish between the two games. This is it for big game changes in the future. :)


Rampant Coyote: I understand Grimm's Hatchery is being made with the Torque Game Builder (TGB). How do you like working with TGB? How does it compare to working with RPG Maker XP?

Amanda: I like it! Both game creation systems have rich scripting systems, and both are great for the type of games they are intended to make.

RPG Maker XP has the best editor for making RPGs period. I've been seriously spoiled by it, and I've not yet found anything that compares. Torque Game Builder is great for the casual game that I'm making (Hatchery). I'm glad that I didn't try to use RPG Maker XP to make Grimm's Hatchery, and I'm crazy glad that I didn't try and use Torque to make Aveyond.


Rampant Coyote: So once Grimm’s Hatchery is released, you will be back to work on Aveyond II: Ean’s Quest. Can you talk about it at all at this point?

Amanda: Sure! Here's a quick overview:

Ean (m) and Iya (f) are two young elves who live in a far away place called the Vale. One day, Ean wakes up to find that Iya, his best friend is mysteriously missing and that no one remembers who she is. Not only that, but a very strange thing has occurred... snow has fallen in the Vale. Ean sets out on a quest to find his missing friend; a quest that will take him away from his beloved home to the mainland below. And on his quest, Ean will find that dear Iya has been swept away by the Snow Queen, and that her heart is slowly turning to ice. Ean must save his friend and Iya must learn to control her wild powers that the Snow Queen desires for herself. The fate of Ean and Iya are the key to defeating the Snow Queen's terrible plot to cover the world in ice.


Rampant Coyote: So how do you approach game design? What goes into a design document for an Amaranth game? Do you involve others in the design process?

Amanda: At this point, I'm the only one in the design process, but when I get suggestions from those I work with, I tend to implement them. To begin, I write the story, then I decide how many quests that the game needs to have, what areas need to be in the game, and then I fill the rest in as if I was writing a novel... layer by layer by layer.


Rampant Coyote: A lot of the older mainstream games, particularly RPGs and adventure games - were the work of very small teams, and were often designed by a single designer. In fact, the name of their designers were in some ways a brand for those games, and a lot of people felt that the tiny design and development team allowed the creators to inject a lot of their own personality into their games. Do you feel that is the case with your own games? Is there anything you could point to - or that has been pointed out to you by friends - that seems to be "signature Amanda Fitch?"

Amanda: Absolutely! I love being devious to my characters in a light-hearted way. For example, in Aveyond, militant squirrels are out to rule the world, and you can join them and follow the Way of the Nut. Of course, no matter what you do for the militant squirrel commander, he will always find a reason to whip you.


Rampant Coyote: What makes a great RPG?

Amanda: For me, a good story, lots of quests, lots of villages, and loot!


Rampant Coyote: What games are you playing right now (if any)?

Amanda: Drats! I've been caught... Er, none at the moment. I've cut myself off from everything until I finish Grimm's Hatchery.


Rampant Coyote: Are there any other indie games out there in the market right now that you are particularly interested in or admire?

Amanda: Cute Knight!


Rampant Coyote: Me too! I’m really hoping her fans will talk her into making a sequel! So, is there anything else you'd like to add?

Amanda: Thank you so much for this interview! If anyone wants to keep up-to-date on the progress of Grimm's Hatchery, my new super-secret Amaranthia Kingdom web project (sssshhh!), or Aveyond II: Ean's Quest, please check out my designer journal, which I update every week: http://www.amaranthia.com/journal


Rampant Coyote: Awesome. Thank you, Amanda, for taking the time out to do this interview. I hope this hasn’t impacted the release date of Grimm’s Hatchery! :)


(Vaguely) related Tales:
· Interview with Scorpia
· Interview with Mike Rubin (Vespers 3D, 3D Interactive Fiction)
· Aveyond!
· Aveyond 2.0 Released!
· Tales from the Road: Cute Knight
· Pre-Teen Game Designer Poised To Take Over the World
· The Evolution of Computer RPGs
· Torque News

Labels: Adventure Games, Aveyond, casual games, Interviews, Roleplaying Games, Torque

- posted by The Rampant Coyote @ 8:00 AM (Permalink) 6 comments links to this post

 
TGEPlus: Two Game Engines In One!
So what do you do if you have two game engines that nicely complement each other, but you don't have the capacity to use them both? Well, in my case, I smashed the two of them together to get the best of both worlds. It helped that the two engines were both variants of the same technology and were, in fact, originally designed to coexist peacefully.

I'd been lamenting the fact that as cool as the Torque Game Builder (GarageGames' relatively new 2D game engine) is, I really didn't have an upcoming project that would take advantage of it. Sure, I'd written a couple of small, non-commercial games with it that helped me understand the system, but realizing that it'd be 2008 before I could even THINK about putting it to use in a major project.

On the other hand, on my wish list of features for the Torque Game Engine has been an improved UI editor and UI tools. Torque's GUI tools, out-of-the-box, are fairly spartan. Sure, they get the job done, and allow the creation of some fairly powerful interfaces. In a straightforward, build-a-UI-with-MFC kinda way. But if you are going for flash - animated menus, elements fading in and out, controls that responded to changes in the game, or anything else really DYNAMIC --- well, it's time to crack open the ol' C++ engine again and extend a class. Or, at the very least, create a dozen artwork variations to deal with the fact that you can't rotate or mirror UI elements.

For an upcoming project (not Apocalypse Cow), this is something of a headache. It has a LOT of dynamic UI elements, which need to slide around, rotate, and fade in and out on the screen. If it weren't for the fact that the principle gameplay needs to take place in a 3D environment, I would have chosen to go with TGB as a solution, as it's perfect for that kind of thing.

The answer was to try and integrate the two. After all, TGB was built over the top of Torque, right? Searching through some posts on the forums, I found a comment by Josh Williams (link HERE if you are a TGB owner) which raised my hopes - though it was suspiciously 18 months old:

'Well, here's a mega-quick guide to putting T2D in TGE:

1) Copy the C++ source files in the engine/T2D directory over to your TGE
project (copy them into your directory, and add them to your compiler
project)

2) CompileAnd there ya go. :)

We designed T2D specifically to be drop-in compatible with TGE like this.
Maintaining this constraint was quite painful, design-wise. There were many
times when either Melv or I said "man, forget Torque compatibility, this sucks."
Luckily though, when one of us said that, the other guy was like "come on...
this is important" and then we figured out a smooth way to keep the code clean
but still do what we wanted from T2D's p.o.v. So, we pulled it off, and it's
extremely easy to integrate these two projects now. Should always stay that
way.'

Well, sure, but that was back in Torque 1.3 & ancient early adapter "Torque 2 D" days. Could it be that easy?

Well, no. There were some minor compile issues. Still the project only took me about twenty minutes, including time to go get a drink from the fridge. When I tried out the resulting code, the results were hopeful but.... glitchy. Still, it looked like I had the capability to put in automated, animated UI elements in my code. It would need a bit more work, but I was optimistic.

Later, Gary Briggs popped on with suggestions from his own success combining TGB and Torque 1.4. The thread, if you have access to the forums, is HERE. There were a lot of little things that needed to be fixed.

I spent some time integrating in the new changes (total time: Maybe a little over a half hour to hunt everything down, copy them over, make the changes inside files, and add them to the project in Visual Studio.) The result?

Well, the resulting executable wouldn't run the TGB Editing tools. Okay, it would run it, but would pop open an error. I should probably go through the whole thing and do a DIFF to see what else needs to be done.

However, I also ran a couple of the games I'd created in TGB, substituting in my new executable (which was also being merged into the changes I've been making for Apocalypse Cow) instead of TGB. The result?

Flawless execution.

FLAWLESS!

Granted, my games weren't exactly stress-tests of TGB. But my resulting project, which I have dubbed "TGEPlus," grants me all of the enhanced UI functionality I anticipate for next year's game. Plus, I intend to use it where I can for Apocalypse Cow. 2D particles in screen-space. Animated menus which slide in and out of the screen rather than just "popping" in and out of existance. Maybe little 2D cows that peek over the edge of the screen with signs that read, "EAT MOR PEEPLE."

Not bad for only one hour of effort. I'm not ashamed of taking advantage of other people's hard work. That's one of the many advantages of using a popular, third-party engine. Kudos to GarageGames for trying to keep them compatible.

Now, the cons:

* Buying a second Torque engine may be a bit too pricey for people who are only interested in enhancing TGE's UI functionality.

* As I mentioned, my merge is still not perfect - it doesn't work as a replacement for TGB with the tools suite. Some more work needs to be done - though I don't know if it's a priority for me, personally.

* My final executable clocked in at around 4.9 megs for the release version executable. It had some additional code from my current game, but a small enough amount to be in the noise. TGE comes in at a pretty hefty size to begin with, and so the addition of the TGB library may not entirely tip the scales - but it's a definite impact when considering file size for a downloadable game.

Again, many thanks to Gary Briggs and the GG team. The effort is appreciated!

Labels: programming, Torque

- posted by The Rampant Coyote @ 11:31 AM (Permalink) 5 comments links to this post

 
Torque 1.5 And A Torque Wish-List
Over at GarageGames.com, Torque 1.5 is now available. It's $50 more than the original, but is available at a discount if you already own an older version of the Torque Game Engine.

I haven't had a chance to check it out yet, so I have to go by the changelist (which I think you need an account to see). But here are the key details:

* Torque Lighting Kit is now an integral part of the engine (it's about time!!)
* Torque ShowTool Pro is included (it's a valuable tool, and also past due for being included)
* Various improvements and optimization on the lighting (above and beyond TLK)
* New multithreaded profiler
* Updated the waterblock system to work with different terrain sizes (YAY!!!!) and they can now be moved in the editor again.
* Particles emitter fixes. I hope this prevents particles from dissapearing when their emitter is barely off-screen (sounds like their bounding boxes are now handled correctly, so you CAN prevent this from happening - FINALLY!)
* Engine and GUI Code brought up to current TGB level.
* An Elf character, new skyboxes, and some sample art from various content packs
* Alt-Tab fix for windows
* Fixes for client-only explosions (A YAY with contingencies... I really need to see how well they work now)
* Some long-overdue audio fixes
* Improved Axis Gizmo in the editor
* Bunch of work to bring Linux & Mac code up-to-snuff.

This is all well and good, and arguably worth the $50 price increase. (Actually, IMO, just adding the lighting pack and the ShowTool Pro was probably worth that). But here are some things I'd really like to see for a future release (hopefully not one with an increased price tag or an upgrade cost, but we'll see):

* MASSIVE improvement on the UI editor and UI elements. It's still a pain in the butt to use, and buggy when you try different resolutions. Ideally, the editor would see serious improvement to make it more of a WYSIWYG tool. Also, I'd like to see some more functionality in the actual UI elements, borrowed perhaps from TGB. I'd like to see animated screen elements - the ability to automatically cycle through texture animations, to automatically translate, rotate, and scale.

* Better documentation - to the level of what the Torque Game Builder currently offers, at least. A few "build your own game" tutorials would go really far.

* Full-on refactoring of the ShapeBase object & how it is subclassed. Making a custom subclass (in C++) of shapebase is a big ol' hairy pain in the neck!

* Good documentation of the C++ elements of Torque - especially working on things like ShapeBase subclasses, how you pass things from client to server cleanly (and optimally) over the network, synchronization issues (tick updates and interpolating between ticks), ghosting, camera control, etc.

* Release the Forest Pack! Or better yet, integrate it into Torque.

* Better handling of large interiors, and directly-linked interiors (with a portal between them).

* Vastly improved support for SINGLE-PLAYER games. Like better ways of bypassing the networking, or more automated ways of handling updates between client & server for games that take advantage of the fact that the client and server are on the same machine.

* Better / more intuitive / more powerful camera control, especially with respect to single-player games. Sort of what has been done with the advanced camera resource, but cleaned up, improved, and with true framerate independence instead of the "fudging" that's currently being done. Also with better support for animation & cutscenes, true zooming, etc.

* Support for localized fog (instead of just global fog settings) for area-based special effects.

* Built-in support for Python / LUA scripting. Just because I'm wishing. I guess I should wish for a million dollars, too, while I'm at it. It's not that I don't like TorqueScript... but it's not nearly as powerful (or as intuitive) as these languages.

Maybe some of these are already in 1.5, but it didn't seem so judging from the changelist. But hey, I can hope and dream, can't I?

Vaguely related rants and raves about Torque:
* Torque Game Engine Deal
* Torque News
* Torque Game Builder Quick-Take Review
* On Game Engines and Swarm Missiles

Labels: Torque

- posted by The Rampant Coyote @ 8:49 AM (Permalink) 8 comments links to this post

 
Torque Game Engine Deal
It looks like GarageGames is offering a pretty nice limited-time deal if you do not have their core product, the "Torque Game Engine," yet. Release 1.5 is coming out "soon", bundled with tools (including the Torque Lighting Kit, which I always maintained should have been part of the core engine a long time ago) and content to make it worth the $50 jump in base price.

I already have TGE 1.4 and the lighting kit, so it'll cost me only $25 to upgrade - which basically gets me Show Tool Pro for only $25. Not too bad.

The big winners are those who purchased the Torque Game Engine since August 1, 2006. That includes those who buy it RIGHT AWAY (before 1.5 is officially released), so you can score the whole kit and kaboodle for only $100.

Details can be found here.

Besides the integration of the lighting kit (which is, admittedly, awesome) and inclusion of ShowTool Pro and extra "starter" content, there's not much information as to what is changing with 1.5. I know at one point they were talking about 1.5 being vastly streamlined from previous versions, but I think they may have departed from that roadmap. Apparently they have FINALLY fixed the issues with waterblocks and re-scaled terrain sizes, which is nice.

My Take On the Torque Game Engine (1.4x):
I've had a love/hate relationship with the Torque Game Engine for about a year-and-a-half now. It's an incredibly powerful engine, but it should come with the equivalent of a "Some Assembly Required" warning sticker. I wish it was half as easy to use as their 2D product, the Torque Game Builder (TGB). And that it's internal code was as well-designed and easy to follow as TGB's (yes, I know the TGE code is at a layer underneath TGB, but I'm talking TGB-specific code). I also wish it was as well documented as TGB.

Maybe they'll get there. Maybe I'll be stunned and surprised with 1.5 and see that they are heading that way. I don't know.

The thing is, TGE is fabulous for putting together a prototype for a first-person-perspective game. The scripting language is... well, unique, but not too hard to get a grip on if you know C, C++, Java, Python, PHP, or similar programming / scripting languages. TGE can do a lot of amazing things.

But to do something really cool, you are going to need to get in under the hood, and the organization and documentation of the source code for TGE leaves a lot to be desired. It definitely shows its ad-hoc development methodology and evolution over many years. There are member variables that say they are supposed to do things that they don't do anymore (or never did). There are weird limitations that you won't know about until you trip over them and tear your hair out wondering why things won't work.

In other words, is about like every other game engine out there, only it bears a few extra years of kruft.

On the plus side, it's got a pretty decent terrain & water rendering system, both interior (BSP-style) and exterior rendering with a portaling system in-between, good multiplatform support (Linux & Mac), a decent built-in animation and partical system, a very robust (albeit proprietary) scripting system, good tool support, a pretty stellar networking system, built in GUI-building tools and a mission / terrain editor. It also remains fairly compatible with older hardware, which is important for indies who may not be catering to the same audience as mainstream.

And it has solid community behind it, and gives you access to source code. Which are requirements for me. And it comes many, many man-years worth of development and debugging. If you've ever worked on a game project through completion, and you understand the meaning of the 80/20 rule (80% of the work takes 20% of the time...), then you'll appreciate that last one a lot more.

With the Torque Lighting Kit, it also has some really, really impressive rendering. Including some nice detail-mapping for interiors.

So it's a great engine, and a bargain at the price (especially if you sneak in during the free-upgrade window), but at least past versions haven't been very newbie-friendly. Approach with your sleeves rolled up.

Labels: Torque

- posted by The Rampant Coyote @ 12:33 PM (Permalink) 5 comments links to this post

 
Torque News
There are a few interesting things happening of late on the GarageGames front that may be of interest to indie developers - even those who don't have anything to do with their engine or tools.

For those who use the Torque Game Builder (my quick take from a few months ago can be found here), it's now up to version 1.1.1. I've played with the new version a little bit since it's release several days ago. The first thing I encountered was that the animations of my 3D shapes no longer seemed to work. I don't know if that was an artifact of the code merging I did, or if it's a new bug.

I'm really pretty frustrated about the problems with the t2dShape3D class - the biggest being it doesn't work under DirectX. That was the key ingredient of the "special sauce" that made TGB interesting to me, and it's still not quite working as advertised.

In spite of my pet peeve, I do have to admit the engine is really looking quite sharp. There are two key changes (to me) with the new rev that really make it exciting. First of all, they've added a new sorting system for objects so that they can be sorted by Y values. Looking through the code, it looks like they've got similar sorting for X values, too, but it's not been documented and I've not tried it out. So I can't say if it works or not. But it would certainly make something like this far easier to do:



The other key feature is that tile maps are now integrated with the level editor. I have had a chance to play with this feature a little bit, and it really makes a huge difference, particularly in the early prototyping stages.

Hot on the heels of this release (enabled, one might say, by this release), is the new "Torque Game Builder Adventure Kit". I haven't looked at this one yet, but it looks very intriguing, as you can tell by the screenshot on the right. The new release of TGB + the Adventure Kit really seems to target the isometric RPG development community.

It's up against some heavy competition, so I'm not sure how well it will do. TGB plus the adventure kit is $140 - $240, which gives you a skeleton to create a pretty decent 2D RPG. However, there are far more complete tools already out there, such as RPG Maker, which also have a lower price point. The biggest difference is undoubtably in flexibility, but at a cost of more "do-it-yourself" work. It'll be fascinating to see what emerges.

Torque-X is probably GarageGames' biggest coup to date. An engine that lets you program games for the XBox 360? I can't think of a bigger PR move or a better way to make Torque the "engine of choice" for legions of wannabe game developers. Hordes of XBox 360 fans with visions of making their own "Halo 2, only better?" Yeah. Score for GarageGames. Not that I want to disparage said dreamers who will be signing up for Microsoft's "Creator's Club" developer program. I'm sure there are going to be some excellent games appearing in their network as part of this program (not "Halo 2 only better," but quality games nonetheless), and it will undoubtably be a key part of the genesis of many future professional game developers. And indies! And I will conceed that the Torque Game Builder tools for Torque-X will likely vastly improve the chances of these guys losing their "wannabe" status and actually creating and completing game for the console.

And finally, the big news last night was that the Indie Games Con for this year was cancelled. This sucks, as I was finally going this year (with my boss at Wahoo Studios). We had tickets and everything. I can imagine the reasoning behind this move. Torque-X is GarageGames' ticket to hit some excellent traction in the game development world (not just indie, but game development in general), and so I can understand how they'd want to focus their resources into that rather than into the conference. In addition, indie and "casual" game development conferences have been appearing all over the place of late, with the explosive growth in the casual games market - with apparently more financial backing. I can see why GarageGames might have trouble making the IGC stand out without just becoming an out-of-town "Torque User's Group" meeting.

That doesn't change me being annoyed. Oh, well. Those are extra days on my schedule that I can now devote to game development, I hope.

Labels: Torque

- posted by The Rampant Coyote @ 7:57 AM (Permalink) 2 comments links to this post

 
Indie Interview: Mike Rubin pt 2
This is Part 2 of the interview posted yesterday with Mike Rubin. Mike was gracious enough to answer some questions about his "3D Interactive Fiction" project, Vespers 3D.

You can read part 1 by clicking HERE.

Rampant Coyote: When you move from a more abstract representation of a world to a more concrete one, those kinds of things are bound to come up. I've heard similar things from experienced "Pen and Paper" RPG designers moving to computer games. And even from doing conversions of board games to computer games.

I would imagine that you aren't the first one to think of pairing up Interactive Fiction with a 3D environment. Do you know of anyone else who has succeeded? If not, why do you think they failed? If so, what are you doing that's different (other than telling a different story)?

Mike Rubin: Well, I can't say I'm completely familiar with all of the different attempts that have been made in the recent past with respect to graphical adventure games. But I'm pretty sure that nobody else has taken the approach of incorporating this much text into the game. The text in traditional IF performs many functions; it is descriptive, narrative, informative, aesthetic; and of course it is used for interaction. Is there no role for that in a graphical adventure game? I think there certainly is. Perhaps not in the descriptive sense (that would probably be redundant), but certainly in its other roles. And I don't know of any real-time 3D games where a text parser is used for command entry. So in that sense I don't know of other games which have really tried to incorporate interactive fiction per se.

I think people will always point to the Myst series as the best-known implementation, and they did use real-time 3D in their later efforts. Some people really liked those, but I have not played them all. Our story is different, yes, but I also think we will differ in how we tell the story and how the player experiences it.


Rampant Coyote: How do you think the Interactive Fiction community will respond to a real-time 3D I.F. game? Do you worry they'll cry out for your blood for polluting their beloved text with something that looks like a First-Person Shooter? Or is this something that the community has already been asking for?

Mike Rubin: It's a fascinating discussion to me, and on one hand I'm eager to see the reaction and on the other I'm dreading it. I'm sure there are people in both camps, although I couldn't really tell you which outnumbers the other. I've spent some time lurking in groups like rec.arts.interactive.fiction and there have been dicsussions in the past about making 3D adaptations of IF, but most were met with strong skepticism. I think there are definitely some IF people who would like to see this, but there are probably a lot who will reject it. There are, after all, hard feelings still lingering towards people like Roberta Williams (of Sierra On-Line) for initiating the demise of the text adventure game when the first graphical adventures came along.

One thing that I think will lead to some indifference is that 3DIF is much less accessible to the individual developer than text IF. Most text games can be developed by a single person over a relatively short period of time, and with some of the new tools like Inform 7, very little programming skills or knowledge is needed. I think that's one of the things that binds the IF community together; it's not a commercial enterprise, it's a group of like-minded individuals working on their own projects and helping each other out and playing each other's games -- and they're all free. A 3DIF game takes a group of people with different sets of skills, some cash, and a lot of time. When the community gets their hands on this I'm sure one of the first reactions will be, "can I do this with my game, too?" The answer will probably turn many of them off because it's very different from traditional IF.

I think some parts of the community are really looking for something new to spice up the IF world, and I hope this fills that role. But it's hard to say if it will.


Rampant Coyote: Do you think that Vespers 3D will help expand Interactive Fiction to a new audience? What kind of market do you expect to find for a game like this?

Mike Rubin: The IF community always seems to be looking for ways to expand their audience, and if this project can do that, I would be happy about it. I don't suspect that will necessarily be the case, but you never know. What I would like to see is people trying Vespers3D, and then trying the original text version to see how they compare. If that happens, I'm sure there will be a number of people who find they like the text version better, and perhaps they will be inspired to try other text games as well. I'm considering distributing the text version and its IF interpreter with the game, along with some information to direct players to online repositories where they can try other IF games. I think that might be an interesting tact and something of an offering to the IF community, since I'm still really an IF enthusiast at heart.

I'm not sure what kind of market we will find, but I'm certain there is a market for it. I think Myst showed that you can be very successful with games that are slower paced and focus more on creative problem solving rather than fast-twitch reaction times. But Myst succeeded for a number of reasons that don't necessarily apply to our project, so it's hard to say. I think it will definitely be a niche product, but I also think people will appreciate it for what it offers.

Rampant Coyote: Do you have any projections for when Vespers 3D will be complete? Is Vespers 3D a commercial project? How will you be distributing it?

Mike Rubin: I would like to be able to project that, but I really don't know. We're still at a very early stage, and a lot will depend on finding additional help for some areas of development.

Whether or not Vespers3D will be a commercial product was and continues to be a topic of considerable debate amongst our team. Originally, we planned on producing only part of Vespers; the text game takes place over three days, and we considered producing only the first day as our proof-of-concept prototype. But I think we all agree now that it will have a much greater impact as a complete game. That said, it will require a significantly greater investment to do the whole thing, which complicates matters. I'd still like to do the whole thing and release it for free, but only if that's feasible and if we believe it will help us with a future (commerical) game.

As for distribution, we haven't really discussed that yet, and of course it will depend heavily upon the decision above.


Rampant Coyote: So what other games have inspired you? Any indie games?

Mike Rubin: All indie games inspire me. Any individual or small group who can start and finish a game deserves a great deal of credit, and that includes IF authors. But I'm more inspired by those games that try to do something new and different, which is really what the indie game dev community is all about...doing the things that the big game companies won't take risks on. I wasn't really part of the indie community until I got involved with the Torque Game Engine, and now I've met some pretty inspiring people. Two games that were recently completed using TGE are "Minions of Mirth" and "Wildlife Tycoon: Venture Africa", and it was pretty cool to watch them progress through to completion. WT:VA was a finalist at SlamDance last year, and now you can find it on store shelves at places like Best Buy, which is just amazing to think about. I can't imagine how it would feel to walk into a Best Buy and see Vespers3D sitting on a shelf.


Rampant Coyote: What are you most proud of in Vespers 3D?

Mike Rubin: I'm pretty darn proud of the text parser, which is a form of punishment I wouldn't wish on anyone. Text parsers in IF games may seem pretty simplistic, but there is an incredible amount of complexity to them. The funny thing is that they have evolved to handle some pretty complex commands -- but the reality is that the vast majority of commands they handle are still simple one or two word phrases. But the expectation now is that a good parser should be able to handle those difficult phrases, so the bar has been raised and people will expect your parser to live up to that standard. I think ours for the most part will.

But really the thing I'm most proud of is that we've made it this far. Indie game projects are kind of like fish eggs; thousands are laid but only a handful survive to adulthood. We're not anywhere near the end, but we've reached something of a milestone this month. There's a tangible sense that the concept will work and the team we have is good enough and committed enough to pull it off. It feels like we have passed the point of no return, so to speak.


Rampant Coyote: Incidentally, two of the few games I actually "finished" in the Commodore 64 days as a budding wannabe game programmer were text adventures, and I remember all the effort I put into the text parser, and how proud I was of it. They still weren't quite up to Infocom standards, but I felt I could take on the Scott Adams adventures pretty handily.

So, getting even more technical for a moment here: What made you decide to use the Torque Game Engine for Vesper 3D? Is this your first project in Torque? What has been your experience with Torque so far?


Mike Rubin: I chose Torque because I wanted an engine that was inexpensive, cross-platform, simple to license, and came with full access to the code. I also wanted one with a simple scripting language. Torque fit those criteria well, although one or two others did as well. I looked for a long time at Unity, which was appealing because I'm predominantly a Mac user. I chose to go with Torque mostly because of the great community there, which seemed a bit more established than Unity's. People at GarageGames.com have been really helpful and there are just an incredible number of resources there to help make your game better. This is my first project in Torque, and it's amazing to think about how much I know now compared to when I started last fall. And it's just as amazing to think of all that I still don't know.

Working with Torque is one of those experiences that is hard to characterize. It's probably in some small way similar to raising a child; it's incredibly difficult and when you start out you have no idea what to do or how to do it, and you spend a lot of time struggling. But every now and then you stop and look at what you've accomplished, and you realize you've actually enjoyed it all and you're really proud of what you've been able to do.

But then again, I don't have kids, so I can't say. (At least that's what all my friends with kids tell me.)


Rampant Coyote: I'm still fussing with my first Torque project myself. I know I get a little embarassed by some of the earlier code I did --- it seems like after a point you quit kicking and screaming at the engine and things just start to "click."

So, is there anything else you'd like to mention here?

Mike Rubin: Just that any project like this is almost never attributable to just one person. I owe a lot to Jason, N.R., Jon Jorajuria (our sound designer) and a few others for all of their help and their skills, and for making this project both attainable and a lot of fun. And I should really be thanking my wife for not kicking me out when I spend far too much time coding on my spare time.


Once again, thank you, Mike, for this interview!

(Click Here For Part 1)

Labels: Adventure Games, Interviews, Torque

- posted by The Rampant Coyote @ 8:00 AM (Permalink) 0 comments links to this post