Torque ok for RPG's or something else?

#21 @Tony

Quote:You really should know who you are talking to before making a post like that. You can make an API that is flexible enough and easy enough to use that you're not required to modify the source code simply to get your game to do what you want.

Uhm, I never said you could not make a flexible API. I think you missed my point. The biggest point being that you seem to try and force YOUR opinion/ways on us (reread your darn parrot story, you are doing exactly that). "Torque's hard, Torque's hard, squawk!" (toung-in-cheek)

It was a clear-cut question that only needed a clear-cut answer. If the author needed a long answer with a jaded opinion, they would have asked after being told Yes/No.

I'm not trying to flame you, just making MY point, yours has been stressed multiple times in this thread. If you don't like my opinion, that is fine. I can agree to disagree with you. You should learn how.

I respect you for your contributions to the community here at GG. This thread doesn't change that. It's called a debate, difference of opinion, or in some cases and arguement. But it stops there. Alright, I'm done thowing my "virtual weight" around. Moving on now...

#22 I see your point, but I suppose I didn't get it since I have used Torque for several years and I'm saying "Torque is hard" out of experience, not out of hear-say.

Don't get me wrong... making games is hard too... but there is a whole lot more involved in making a game than just the technical hurdles.

All I'm saying is that if you're making an RPG like Morrowind with Torque then that's kinda like dancing a ballet in combat boots.

Granted, a lot of people cannot dance even if they were given magical slippers with pretty bells on them, but even the best of dancers would have a difficult time dancing in combat boots.

Is it impossible? No... is it harder? Absolutely.

If you have a choice between combat boots and ballet shoes, wouldn't you do your best to choose the right tool for the job?

You're trying to convince this guy he should use Torque, simply because it can be done.

I'm arguing that there are better tools out there that he'd have a much better chance of success.

But conversely, if you wanna show up to a war, I'd opt for the combat boots.... that's about like making an FPS game and pretty much any FPS game I've ever made was best made with Torque.

Torque isn't the end-all-be-all engine and it's not suitable for making every single type of game compared to other engines out there.

I recommended other engines that wouldn't get in his way... probably not ballet shoes, but better than going barefooted and less clumsy than combat boots.

#23 I don't see any valid argument of why Torque cannot create an RPG. Torque has many features built in that will save you many hours of programming and frustration, especially for a first person rpg.

Day/Night Cycles, heck even full featured Yearly Atmospheric Cycle Systems have already been coded for you, ready for you to tweak, not rewrite. There are excellent precipitation, foliage, and environment effects built in. Multiple options for spell effects, be it AFX or simply creating your own using Torque's weapon system. There is a resource for server side melee, and a built in particle system for great spell effects.

Other things like dialog, quest systems, etc. can be done using Yack Pack or the freely available RPG Dialog Resource. There are multiple inventory resources. These two subjects are best to planned out carefully, depending on if you want multiplayer support or not.

There are mesh hiding resources, as well as the Male Character Pack, for a head start on character customization. You can leverage Torques vehicle system to create mountable horses, or dragons, or buggy's in very little time.

Of course, there are some things that will require either creativity, or a very experienced programmer if you want the cutting edge technology. Paging Terrains is not supported, and in my opinion a difficult task to accomplish. You may choose to cleverly add in loading points and choke points instead.

I have never had a problem with Torques loading times. If you set up your game properly, and include the lighting files, loading times shouldn't be a problem. Now, if you create a 4sq km map with 100 buildings, that may be a different story. If you create replicator to do it for you, you've just sped up the process. AI is another area that Torque is lacking in stock, but there are also many resources that give you a leg up. A* has already been implemented, with working state scripts. All in all, your programmers will have some work to do, but will mostly be doing work to make your game be really polished, and not some default click together game.

To summarize, there are other applications out there that may be better for what your team is trying to accomplish. However, Torque is perfectly capable of creating a AAA quality RPG, and will save you a lot of time if you were to create your own engine or modify other existing engines. There are limitations, but every engine has them.

#24 @Tony -

There's nothing wrong with being happy with your engine, or what you want to accomplish. But is your engine done? What it sounds like you are comparing is the current TGE (or actually, an older version, since you were unaware of the updates to AFX earlier) to a hypothetical engine that you may (or may not) complete in the future. Of course any engine that is shipping can't compete to a hypothetical future engine.

Maybe you'll have the greatest RPG engine in the world someday. But you don't have a finished one now - so why do you come in here and hijack every thread about RPG development and push your engine? No offense, but it seems like you have an agenda.

Jaimi

#25 Before I started work on my RPG game I spent several days researching other engines, from a novice point of view. I wanted to be absolutely sure before I spent a lot of money that I was making the right decision to use Torque. I arrived at 2 conclusions -

1 - For a guy like me that is a novice at best with c++ I'm happy to say I'm not smart enough to care or know what Torque shortcomings are. On the contrary, once I finally began to really understand what you could with script, Torque makes it possible for a guy like me to make a game that I am making. If I had to do all this in c++ I would probably be impossible for me. I think that's where Torque shines the best, to give the non-professionals and the non 20 years worth of coding experience a chance to make a quality game.

2 - I visited many game engine websites in my research and I found one indisputable fact, the GG community is second to none. All the other sites didn't have half the activity you see on GG forums. The tools, content packs, resources, etc is all right there for anyone to use and that's a huge bonus.

So yea, I couldn't care less what Torque isn't or what it won't be. I just know I am making a serious RPG with very little coding experience and that wouldn't be possible without Torque.

#26 @Jaimi

My agenda?

I want to dispel this myth:

Quote:Torque is a PERFECT engine to make a game of ANY genre.

Which is better, a clean API or an engine that requires you to change the source? Any answer other than a clean API is wrong... period. Of course, a clean API with the source included is even better.

Modern software design has grown up and moved on in the past 10 years.

Take a look at LeadWerks for a fantastic example of how a game engine as an API works... you don't get the source code, but you don't need the source code.

Quote:But is your engine done?

Do you really want to know or was that a rhetorical question?

#27 TGB is a great choice for a 2D RPG.

TGE (or TGEA) with AFX and a number of highly valuable community resources is a great start for building your 3D RPG.

Quote:Which is better, a clean API or an engine that requires you to change the source?

From the perspective of a game creator and not an engine creator: if the API has inferior content editing capabilities or is incomplete/unproven with no shipped games, I'll take the proven/complete engine with content pipeline and full source for modification...

I have yet to see an API in the strict sense being used here that competes with a complete engine for actually shipping a game. This is in line with the industry and the most licensed engines to date.

#28 @Tony -

No, I truly wish to know. Is it done? A lot of people have great ideas - and even implement them somewhat. But as you know, the last 10% is 90% of the work. I've looked at your site, and all we have is your word that your engine is the best engine to make RPG's with. Unless I'm just missing them, there's no demo, no screenshots, etc.

So I'm asking - Can it compete with what I have currently? Which is:

1. A complete pipeline for creating actors, shapes, and buildings with shaders and fallbacks for older cards.
2. A complete spell and targetting system (AFX is really much more than this, though)
3. A complete conversation system.
4. A quest system, with flags and multiple values/states that can influence the conversation engine.
5. A decent AI, with adversaries that can use a generated (and manually tuned) AStar system to get around, who can fight, use inventory to improve their health, flee to a hiding spot if they get hurt too bad, or try to avoid the player if they're too weak.
6. Ability for the AI to respawn or not, depending on flags.
7. Ability to persist the state of the game to a file, load and save these states.
8. An inventory system.
9. A vegetation system that is specific to terrain type and altitude - Autogenerating the vegetation on the fly, and leaving the roads clear, and the desert with scrub, and the plains full of grass.

That's obviously not a complete RPG engine yet - but this has taken me just 3 months to make, working part time on the weekends (10-20 hours per week). I'm not saying TGEA is perfect, but that's a pretty small amount of time to put together what I have done so far, and have it work just the way I want it to work.

Can yours do all of that now? Will your idea of an RPG work like I expect an RPG to work? Or would I need to change my ideas to work within your framework?

If so, can we see it? Does it really exist - or are they just ideas that you may (or may not) get around to doing someday?

#29

Quote:
Which is better, a clean API or an engine that requires you to change the source? Any answer other than a clean API is wrong... period. Of course, a clean API with the source included is even better.

Modern software design has grown up and moved on in the past 10 years.

Take a look at LeadWerks for a fantastic example of how a game engine as an API works... you don't get the source code, but you don't need the source code.

This is a very common misunderstanding that I feel is part our fault (marketing, and documentation), and part end-user confusion.

Torque, as it is shipped to end users, consist of 2 aspects:

--the core engine, which consists of almost 500,000 lines of source code. There are almost 20 major systems and dozens and dozens of sub-systems that add up to what the Torque engine provides--the list is huge, but just a few are:

--cross-platform/networked object instantiation, tracking, and messaging
--resource management
--3 Space scene management
--abstracted sound and graphics (SFX, GFX)
--fully integrated scripting language
--award winning networking
--platform layer abstraction for OS/platform independent development (with platform layers for Windows, iPhone, Wii, XB360)

Added on to this are two starter kits, which provide reference implementations to get people started for those that need it--examples of how to do many of the common features of both FPS and Racing games, in addition to an additional purchase RTS starter kit.

Tony keeps dictating that Torque "sucks" (I use that loosely, not taking it as an insult or anything) because it's an expected use of our product to modify the starter kits, but he's misunderstanding/mis-stating the intended use of the engine: it is a very, very rare customer that digs deep into the low level functionality of the engine core--and it's certainly not an expected/taught best practice to routinely re-write our fully integrated systems to make your game.

What we expect, and highly suggest, is that you will use the starter kits as references, and starting points (hence the name) for the implementation of your game--see how they use the capabilities of the engine, and either adjust, mimic, or simply learn and move on to your own implementation.

A more fair comparison Tony would be this:

If/when your engine is finished and you ship, and you provide example implementations or starter kits, to then state that no one would ever have to change that source code. If you can both pull that off, and also make a game engine with the flexibility and customization capabilities of Torque, then more power to you--but until you make the comparison equivalent, your concerns are very misleading when stated the way you do.

No one expects anyone at all to start changing source code deep within SimObject, the Sim::, Console::, NetInterface::, SceneObject:: or any of the dozens of other key classes that Torque provides...but the way you group both the example/starter kits and the core engine functionality into one heap, and then state "you have to change source code" is extremely misleading.

#30 You do have to change the source code... the engine source code and not just the non-existent RPG starter kit.

You're really saying that you would recommend Torque for use in an RPG because you don't have to modify the engine and all you have to do is modify the starter kits?

C'mon, no fibbing allowed... You're not talking to someone that has never made an RPG with Torque. I have. It was a pretty cool game and it even won an award... but no way could I have made it without modifying the engine.

I'll reiterate, my agenda isn't to push people over to start using my engine. My agenda is to get a little bit of truth in advertsing from the Garage.

@Stephen -

You stated that it's intended that the starter kits are modified but not the engine. Where is the separation? First... where is the separation? There's one large Visual Studio project that has everything in it. Is that the engine? Is that the starter kit?

I'll tell you. There's not a clear distinction between what you need to modify and what you're intended to use and what is the deep dark internal workings of the engine that you're not even intended to use or modify.

This distinction would be a whole lot clearer if you had a clear cut API and your starter kits were separated from the engine... in all of your engines.

Since there's not an RPG Starter Kit then first I or anyone that wanted to make an RPG would have to code that, right?

Jaimi did a great job in delineating some features that are necessary for a good RPG.

Quote:
1. A complete pipeline for creating actors, shapes, and buildings with shaders and fallbacks for older cards.
2. A complete spell and targetting system (AFX is really much more than this, though)
3. A complete conversation system.
4. A quest system, with flags and multiple values/states that can influence the conversation engine.
5. A decent AI, with adversaries that can use a generated (and manually tuned) AStar system to get around, who can fight, use inventory to improve their health, flee to a hiding spot if they get hurt too bad, or try to avoid the player if they're too weak.
6. Ability for the AI to respawn or not, depending on flags.
7. Ability to persist the state of the game to a file, load and save these states.
8. An inventory system.
9. A vegetation system that is specific to terrain type and altitude - Autogenerating the vegetation on the fly, and leaving the roads clear, and the desert with scrub, and the plains full of grass.

(and as he said, that's only the beginning)

So... the engine has all of these features already? No? One of the starter kits?

Or, you're telling me that all of these features can be made without modifying the engine?

Why is it that quite a number of resources available on this website that are intended to be used for making an RPG modify the engine!?!

My experience with Torque (which is a whole lot more than most Garage Games employees!) is that you do have to modify the engine to implement some of these features, and there are some other features that are "nice to have" that are part of your "standard RPG" that weren't mentioned here that also require engine mods.

And in order to make engine mods, you have to read and understand "almost 500,000 lines of source code" otherwise you risk making modifications that you don't fully understand which leads to a lot of bugs. Not a good idea.

If it's "not an expected/taught best practice" to modify the engine to make your game then it stands to reason that it's "not an expected/taught best practice" to make an RPG with Torque.

Is there a flaw in my logic?

#31 I think it needs to be said here that if an API is used, that does not necessarily mean that you will not need to touch source code. Would it be cleaner and more functional? Maybe, maybe not, depending on how such is implemented.

Personally, though, from where I stand, the arguments made for using an API or using TGE/A are pretty moot, as any special/new system brough to bear on an RPG will necessitate changes to source code- whether that means delving into the 500k+ lines of TGE/A, or into the source code of an API, or even rolling new functions for either a new class for TGE/A or new functions to interface with that API. In the end, if you're innovating, you won't be doing it with anyone's code but your own.

As far as the lack of an RPG starter kit goes, I've thought about approaching GG concerning that, since it's relatively easy to whip one up, but it begs the question of what features are we putting inside it? The features listed in Tony's quote above? Good features, agreed, but what if someone needs more, or less? What if their RPG was to lean towards being a sandbox, and the starter kit did not address that? Or what about a more socially oriented RPG?

The problem here, as I see it, and I'm sure plenty of people will disagree, would be that the nature of persistent worlds is so maleable as to present a problem to anyone looking to present a solution to all of it's facets. Take Multiverse for example- and I believe you were at the first IMGDC, Tony? Were you there when Josh Engebretson schooled the Multiverse folks on MMO design, even though he was basically cobbling together technologies, compared to their one engine geared from the start for MMO's? He was talking and they were taking notes. And the point isn't about him so much as to say that implementation is king over everything, even to the point of someone using TGE with Python and a few other technologies and being able to do more with that in a short amount of time than larger teams have been able to do with an API such as offered by Multiverse.

--continued--

#32 So here I just want to look at the list Tony quoted from Jaimi McEntire:

Quote:
1. A complete pipeline for creating actors, shapes, and buildings with shaders and fallbacks for older cards.
2. A complete spell and targetting system (AFX is really much more than this, though)
3. A complete conversation system.
4. A quest system, with flags and multiple values/states that can influence the conversation engine.
5. A decent AI, with adversaries that can use a generated (and manually tuned) AStar system to get around, who can fight, use inventory to improve their health, flee to a hiding spot if they get hurt too bad, or try to avoid the player if they're too weak.
6. Ability for the AI to respawn or not, depending on flags.
7. Ability to persist the state of the game to a file, load and save these states.
8. An inventory system.
9. A vegetation system that is specific to terrain type and altitude - Autogenerating the vegetation on the fly, and leaving the roads clear, and the desert with scrub, and the plains full of grass.

1) This is basically already offered, and I don't see it as an issues except where some difficulties may be encountered between exporters and applications.
2) Spells and targeting consist of selecting objects, particles systems, and underlying functions that really are part of the combat system. As stated above, AFX and/or the object selection code can do this.
3) This is a problem: Define "Complete Conversation System"? Would that be chat windows, HTML-like links to click to take you to different parts of the conversation, clicking Continue like in WoW, or maybe conversation trees without, or even with AI, like Facade- or maybe the Interrogative system I've developed for canned tree-less dialogs with AI? Or go further and make it a chatbot that you type out your dialog like on this forum and have it parsed? Or maybe something like Mass Effect? And what system out there can offer these things without needing a coder to make these changes to either an engine or to create new API functions?
4) Same problem as above: How much flexibility in the quest system? Would they be pre-written, or generated- or semi-generated? How would you handle global events, or would that be a seperate system? Depending on this system, it would affect the other system- but what if you needed to change the kinds of data that needed to be flung back and forth between them? Again, this begs for code outside of what is offered in any engine or API out there.
5) Another one: How much AI do you want? What do you require for your world? Do you want animals to react the same as your NPC's, or maybe have their own system? LOD AI? Do you want to use hardware acceleration for part of it, or make it interact with the physics systems or with the quest and conversation systems?
6) Compared to all the other questions, this is in the bag ;)
7) Another easy question, but you also have a choice of databases, file file systems, etc.
8) Usually pretty mundane- unless you wanted to put a twist on it. And then this can easily fall into the same problem as that of #'s 3-5.
9) Depending on the features you want, you may or may not get this out of an engine or API. If you get really complex, you might need to roll your own instead of even modifying what you have.

In all of the above, I think the biggest problem is that of how different you want your game to be. Even with Multiverse, you have an API, but they state quite clearly that you can add your own functions, and that statement is important...

I understand that people are very passionate on both sides of the argument for using TGE/A versus using an API geared specifically towards RPG's, but if you have to roll your own code for an RPG with an RPG-centric API, then does it matter if you have to roll your own code for a non-RPG-centric engine? At the end of the day, you would need to be a good coder for either task. You may be better off with an API in that it is more modular, but at the same time, you may also find yourself mucking with the API source anyway if your requirements dictate changes that need to be accomodated in those other modules.

#33 @Tony:

I'm not going to go point to point with you on this, simply because we've had this discussion in the past, and you are firm in your beliefs and nothing I can say will change your mind. I am curious however about a couple of things:

--do you --really-- think you have "a whole lot more experience with Torque" than the majority of employees that work with the engine (keep in mind not all employees even work in areas that relate to technology, so if you're claiming you know Torque better than our sales, management, and finance guys, more power to you).

--in your experiences with Torque, did you have to "change engine source code" for any of the classes besides ShapeBase, Player, AiPlayer, GameConnection, and equivalent level classes? In my opinion, adding a couple of class variables and accessor methods doesn't count--I'm talking extensive re-writes of the system or class itself.

The core engine we're talking about here are classes and systems such as:

ConsoleObject/Con::, SimObject/Sim::, NetObject/NetInterface/NetConnection, SceneObject/Container/PolySoup/Box3D, InteriorInstance, TSShape, SimDataBlock, SimEvent, ShaderGen/Materials, GFX, SFX, AFX(if purchased), and the hundreds of support classes related to these systems/classes.

The reference implementations (what is equivalent to a game) are mostly related to classes such as Player, AiPlayer, Vehicle, Camera, Terrain, and generally classes that are below GameBase in the primary engine hierarchy.

I'll take that starter list we're quoting back and forth, and discuss the major implementation decisions required for implementation, and the general classes that will need "modification"--and each of those classes are going to be in the reference implementation for the starter.fps, not the core engine:

1. A complete pipeline for creating actors, shapes, and buildings with shaders and fallbacks for older cards.
--No changes at all required--already implemented (ShaderGen, Materials system)

2. A complete spell and targetting system (AFX is really much more than this, though)
--AFX. Admittedly, the AFX system does modify some core engine classes, but this is transparent to the new user, since all the changes are delivered as part of the AFX purchase.

3. A complete conversation system.
--handled in script via NetEvents. A more robust/configurable solution would probably be folded into a custom c++ set of classes, because it is a new system that isn't provided by Torque. That's not source code modification, it's custom implementation that utilizes underlying core engine classes.

4. A quest system, with flags and multiple values/states that can influence the conversation engine.
--see above.

5. A decent AI, with adversaries that can use a generated (and manually tuned) AStar system to get around, who can fight, use inventory to improve their health, flee to a hiding spot if they get hurt too bad, or try to avoid the player if they're too weak.
--custom class(es) that read from existing systems (terrain data) and feed existing reference classes (Player)

6. Ability for the AI to respawn or not, depending on flags.
--Torque script

7. Ability to persist the state of the game to a file, load and save these states.
--this is the one area I will concede suggests engine code modification at a significant level. A proper database abstraction layer should most probably be implemented at the SimObject level, which is a core engine class.

8. An inventory system.
--TorqueScript

9. A vegetation system that is specific to terrain type and altitude - Autogenerating the vegetation on the fly, and leaving the roads clear, and the desert with scrub, and the plains full of grass.
--GroundCover system.

#34 Ahhh... I see.

The misunderstanding here is that if you have an "engine" then you distribute the source code and if you have an "API" then you don't distribute the source code?

Distribution of source code doesn't have anything to do with the definition of an API.

In reality every engine has an API... in Torque it just happens to be every header in the engine. Hence me calling it a "bad API" or "nonexistant API".

Conversely, a game engine API also has an engine... except the big nastiness of it is hidden from view. It's still there, but what's exposed to you as an application developer is only the interfaces you need to make your application.

It's about the organization. If you have a good API then you have willfully split out a section of your code and said "Here, use this. The rest of the code, sure you can reference it but for the most part you probably won't need to touch it."

If you have a bad API, you just have all of your code hanging out in the wind, ready to confuse and confound the average person.

The difference is knowing what you need to change and what you should leave alone. What is supposed to be the "example" or "starter kit" code and what is the "engine" code?

If Torque were rearranged so that the engine were a library and the starter kits were the "exe" or whatever, then things would be easier to use. If you further rearranged it so that the public headers were in one location and the non-public headers and implementation were elsewhere then things would be significantly easier to use.

You look in the public headers area and you immediately know what you need to use and everything else you can ignore, at least at first.

You look in the "starter kit" and / or "example" source and headers and you know exactly what it is that you should use as examples and you can start from that or start from scratch using those as examples.

But, then you'd finally have an API... an API to a game engine.

It might not be a perfect API, but you would definitely reduce the "WHERE DO I START?" questions and "HOW DO I USE THIS?" questions.

But, with the source code, you could still modify the engine as needed.

So... I still stand by all of my rants... until Torque gets a better API then it's difficult to use by the average Torque user.

A little bit of improvement here would go a very long way.

#35 To be honest, I thought this might have been where you were going--you are definitely a smart guy, and I figured it was a matter of semantics and organization.

We definitely agree with your points in regards to not only organization, but presentation. In fact, R&D is working to go even further than what you are describing with a much more modular approach to use of the engine itself--components, and re-using components as appropriate for individual development.

We've started to move along that path as well in the areas of documentation, and I know that Michael is spending quite a bit of his effort in figuring out not only how to organize information about the engine, but also present it in a more appropriate manner.

#36 That's fantastic news!

I think everyone will be surprised to see how much easier things become with Michael's and others' efforts.

Let me know if there is any way I can help...

In the end it's not Zen Engine vs Torque, it's Indies vs the other guys ;-)

Working together, we can make fantastic, innovative games.

#37 @Tony - You are an enigma to me, but I love the positive comment and I'm fully on board with that thinking.

Btw, what happened to the RPG discussion?

#38 I'm so glad that, when it came time to code in some of my advanced technological features, I had much more than an API. I had engine code, all laid out before me. I have also learned a ton about programming from the codebase, good and bad, optimizations and areas in which optimization is needed.

If I was working with a closed box purely, some of my current features would simply not have been achievable. My two cents.

Of course, I obviously believe that not only is Torque + ArcaneFX the right combination for RPG coding, but it presents a faster path than other alternatives. So my answer to the original question is Yes.

#39 My beef with Torque, especially related to RPG's is the difficulty... but a lot of that will disappear with... well, dunno how to say it without confusing everyone.... Michael's work? GG's R&D work to make Torque into an API?

Don't think of an API vs an Engine as no-source vs source... think of a good API as a clear cut definition of what the game developer needs to use in order to create his game, vs what's hands-off vs what is example code or starter-kit code. GG can still include the source (and I hope you do) but the source to the engine is less important.. and the end game developer doesn't have to worry about learning the intricacies and otherwise "dark magic" embedded within.

An API vs an Engine is not what most people reading this thinks... for some reason, Game developers have a significantly different vocabulary from other software developers.... dunno, maybe we need more cross pollination or something.

Without an agreed upon vocabulary it becomes difficult for us to understand one another.

Did I have to significantly modify Torque in order to write Fractured Universe? Yes... but how much of that was in the engine vs what should be considered the "FPS Starter Kit" or AFX?

Honestly, a lot of it was AFX, but that was Nov 2006 and AFX has improved a lot since then. Originally it did not work for multi-player games, and was significantly datablock heavy which made it impossible to use if you created a game with 50 levels and 200+ spell types (2 - 3 minute load times suck!), and it simply didn't work for online or MMO games.

A lot of other things that I had to change involved networking for an MMO game... but a standard single-player RPG is not the same as what it takes to make an MMO...

The rest... well, "mesh hiding" is how most people accomplish customizable characters... I did it a different way, but in the long run it accomplishes the same thing. But, to do it required some heavy engine changes.

In the end... I think we agree that there are some things for an RPG that probably you'd have to modify the engine... there are more things that you'd have to modify with the FPS starter kit to make an RPG game (when is someone going to make an RPG Starter Kit!?!). And the remainder? Well, the rest is making RPG specific code which doesn't exist unless you're using something like Realm Crafter.

The most difficult part in Torque has been distinguishing engine vs starter kit vs game....

I'm hoping this will change with some of the ongoing work at GG's R&D department and your work with documentation.

To be perfectly honest, I wrote Fractured Universe with TGE + AFX in 3 months for a "create an MMO game in 90 days" and it came in first place. Not bad considering from day 2 I didn't have a team or even a game design thought out. I recruited a team, we came up with the game design and together we pulled off a nice little multiplayer RPG game in 90 days... MMO? Probably not since we never tested it with more than 20 players, but I was using some net code that I had written for a different project that stood up to several thousand simultaneous users on a single machine without a hitch.

Second place was Witch's Gate written with Realm Crafter. Vickie Eagle is a fantastic game designer and Witch's Gate is a fantastic game.

But... If you ask me, it's kinda hard to defend Realm Crafter as a better engine than Torque after such a victory.... possibly some of that was me and DGI's MMO Starter Kit and not Torque... but there's no way to tell.

Sadly, my main goal during the contest was to limit the scope and not do anything innovative.... that was the best way to win... maybe that had something to do with winning too, because it paid off grandly.

A month or so later, after winning the contest and going to IMGDC and having some great conversations with other developers, I realized that I screwed up and made a non-innovative game with Torque, won the contest, but really lost the war... why? Because being an Indie game developer is all about the freedom to innovate, yet my lack of innovation was what allowed me to win.

That sucks!

It shouldn't be that way.

-----------

I don't enjoy playing games anymore due to the significant lack of innovation. One of the ongoing and most prevalent conversations at Indie conferences like IMGDC is about "Why aren't Indies Innovating when it's their key to success?"

The answer?

Our technology limits our innovation.

Now, don't take this the wrong way because I'm not saying it with any malice.

Torque has been part of the problem, as have a few other tools (I won't name them because I don't want to cause additional problems).

Please realize that this statement is not an insult to anyone.... Torque is a fantastic piece of software.

Why is Torque et al part of the problem? Because they limit innovation. They are not innovative. They are just following in the footsteps of our commercial counterparts.

The tools that we use, the engines that we use, the game design patterns that we use should foster, enhance and leverage our strengths.

As long as we're doing nothing but mimic the commercial guys like EA, Blizzard, etc, we're never going to win.

Their strengths are about being able to throw massive resources at a game, millions of dollars, hundreds of developers, and a whole lot of man-hours devoted to technology.

Our strength?

Innovation... we can spend hundreds of hours risking everything on a fantastic new genre of game. We have the ultimate freedom of choice to do as we please... yet we don't. (That's a generalization, please if you do, don't worry about it... most of us don't and kudos if you do)

I can point out weaknesses with every single one of the tools that we use to create games. They cater to the strengths of the commercial guys (i.e. massive manpower) and they do nothing for us.

I can also point out ways we can improve our tools and overcome these weaknesses.... and I can help fix these weaknesses.

This isn't about me, or IndieZen or Zen Engine, or Garage Games or Torque... it's about the Indie 2.0 Revolution... it's about all of us banding together, helping each other out by collaborating on common goals while we individually create our own games.

It's about Indie games being better, more innovative, more fun, and more importantly... more successful than anything the commercial guys can create.

Today is our day.... are we going to waste it or take advantage of it?

#40 Oh, and sorry for the topic change... at least the first part of the post was on topic :P