Game Engines

#1 IMHO, Game maker is not bad, but at this point you should consider Torque 2D (a bit harder but very flexible).
I tryed game editor, if I understood well what "crap" means, I can say is crap. (bad).
However, you should consider also blitzplus or blitz3d, darkbasic, the games factory, multimedia fusion, macromedia flash.

Bye, Thc.

#2 As a side note, Blitz and DarkBASIC are language wrappers with built-in functionality to make game development easier and more intuitive. They're not really "engines." You'll still have to program your engine. You just won't have to deal with the lower levels of programming for the included pieces.

#3 I played with verge-rpg along time ago. it was pretty easi to use and didn't take much to get the hang of it. course..... depends on what you want your games to look like. I heard TorqueTD is easy to use and you can do alot more with it. GarageGames claims Torque TD is the most power 2d engine on the planet.

#4 David, as a side note almost none of the programs I suggested are actually a real engine, but wrappers of something with WISIWYG interfaces for almost all programmable aspects of the (available) objects/options/whatever.
But blitz and dark basic do the job, especially when talking about 2D; multimedia fusion was direct opponent of macromedia flash in the past and the games factory is based on that; macromedia flash has becomed almost a standard in 2d gaming, especially for online playing.
Let's stop this religious-fanaticism in regard of Torque, there's not just Torque in game development. Is not the absolute best, even if is not the worse. Just does the job, as well as every engines.
Well, Torque has many problem solvers inside and it's well structured but these days there are many engines wich are graphicly capable as much as TGE and they are all hobbyst engines.
About TSE, there are some great engines coming up that have similar graphic features, the multiplayer concept was strong when Torque was born because it was the step forward.
Now I see indie engines managing 32 player connections with no problems. Some include even an evolved AI interface or the multiplayer physics (but not both, unfortunately).
You can also consider TorqueScript itself as a wrapper around Torque's functionality, what gives the feel of professional here is the presence of the source code gived to licensees but I never saw something done with script only, so this turns in a double blade weapon and by the other side it's an evidence of how is Torque not really general purpose, but highly customizable.
This is not the same thing, pay attention: a real general purpose engine would let me use whatever development method I wish, choosing from the available methods while a higly customizable engine would give me the ability to add what I need by one way and use it by another, like C++ for adding features and TorqueScript to use them.
Even the ability to use Torque as a library or adding support for other development methods requires customization, while in a general purpose engine usually you get just one method or any but directly from the developers. If you have to do an action game Torque is good, even for a action adventure, a racing game is OK, on whatever type of vehicle (but not water vehicles, not directly supported) but what about the other genres? I don't think Torque is ready for a RPG, Tycoon, sport and so on, at least not out-of-the-box. This means I can customize Torque to fit my needs, but not that Torque is general purpose. So, let's stop this religious-fanaticism.

Bye, Thc.
.

#5 The only other product I have been impressed with is Blitz3D.

I have had to use A6 for some contract work in the past and wasn't impressed at all.

Torque seems great if you are developing something that fits within the constraints of game types it has already been developed for, and Multiplayer games in particular.

Blitz is an excellent product for developing quick casual games through to fairly advanced games, but for 3d isn't cross platform, and pretty much forces you to write an engine and editors from scratch, which can be quite daunting.

THe language is far better than basic, and tailored towards 3d game developed towards games. Offers you a lower level control of assets than you get in torque script, but not as much as you have through C++. Whilst being very friendly for intermediate programmers.

For basic programers it's a nice way to get an introduction to programming and game development, but to make a good game you still need a lot of programming experience. And artists that understand how to get the optimal perfortmance out of a render engine that is somewhat outdated but does run on a broad range of ageing hvideo hardware.

Appart from Torque and blitz I can't really recommend anything else. Tried a lot of things in the last 4 years and only those impressed me enough to keep my interest enough that I use them and am an active part in their commuities.

#6 I believe this is more constructive than the usual "torque is the best".
However, this really depends on what you put major attention on.
If you are looking for built-in functionality, Torque offers more than anything else for the genres that at our days go better.
But if you are looking for good graphic (like me) and care no or little about what is left to code, there are plenty.
Unfortunately, buy them all would be lazyness and I feel good with TGE but I have to admit I'm trying some free one.

Bye, Thc.
.

#7

Quote:I don't think Torque is ready for a RPG, Tycoon, sport and so on, at least not out-of-the-box.

There are many RPGs being developed on Torque... even MMORPGs (like Minions of Mirth). Check out one of the recent development snapshots, an WoW / EQ2 like spell system in Torque.

A lot more can be done out of the box in Torque than people will admit or ever allow themselves to learn. The thing is if you plan to make a commercial quality game (yes even if you are making an indie game I'd suggest trying for "commercial" quality even if not commercial quantity) you better plan on making optimizations in an engine whatever engine/language your using. You simply won't get the performance you could by making changes to the engine for the game your making, unless you were to make a complete gameplay clone (which is good for a learning experience but bad for selling lol :).

Now Torque is obviously geared towards FPS and Third Person Shooters out of the box. If it were an "all purpose" engine then you would have to make some hefty modificaitons to make it run efficiently as any type of game, including FPS. Right now if you plan on making an FPS you won't have to make many changes. Now if you do a standard FPS you won't "have" to make any probably, though again you will always gain some performance in tweaking an engine to your game, though thats common sense.

Now if your a hobbyist then Torque is great as well since its got a basic FPS framework already built up. So if you enjoy just building things up for fun then its no problem. Torque 2D as well. It doesn't have every single feature in existence but it sure has a lot and if you plan to make a commercial game you can get some very good results with it as well, and as far as a hobby game its perfect for. Torque 2D is perfect if your either coming from a drag n' drop background (or no coding experience) and want to learn scripting at a basic level, or if you want to skip that drag n' drop step and start learning scripting/programming.

Though there are some arguments that end up with the generic "torque is the best" statement, thats not always the case.

Right now I can't think of anything I can do in Blitz that I can't do in Torque, however vice versa I can't say the same.

Sure I think Blitz is a good step, though I still think I would end up working in Torque when you get to a serious step of wanting to make a commercial quality game. Even if your a hobbyist I still think Torque is great though I do note Blitz's place in that as well as casual gaming.


I hear a lot of people say Torque is limited to certain game types, though I keep seeing games that are either fairly deep into production or near comletion that are all sorts of genres.

Torque is a viable option for a lot of game genres, depending on which genre it might take a lot of work though if you plan on making games then you should start getting used to adapting and learning.

#8 @Thc-03
I have no idea where the fanatacism comment came from unless there were a number of posts that were deleted from this topic or it was misposted and meant for another topic entirely.

In reading through it, though, I think that the major problem is one of vocabulary. When does a library become an API or SDK? Where is the overlap and on what level in a definition? When does an API become an engine? What functionality defines a wrapper language from other types of languages?

I place Blitzbasic/3D/Max (I love BlitzMax, BTW) and DarkBASIC in a wrapper language category because of their focus: languages with BASIC syntax oriented towards being wrappers for gaming functionality. I'm not a fan of DarkBASIC mainly from a performance standpoint, but I like the community and have enjoyed a lot of games made with it. I really like the Blitz community, though. They're a great bunch.

I place The Games Factory, GameMaker, MultiMedia Fusion in the "click-to-create" game engine arena. GameMaker has a scripting lanuage, but one doesn't need to use it. But they are engines. They provide a game framework which is limited by their target audience: the uninitiated. They have simplified the interface to the engine and accessbility to cater to their audience. That's not to say that some nice games haven't come from them or that they aren't good for new developers to get their feet wet with.

Torque, Irrlicht, Cube, Cipher, A6, The Nebula Device, Unreal, Quake, etc are game engines that provide a set amoung of functionality through which a full game can be made with limited resources (not from scratch). They also provide an extensible framework. Each one has their strengths and limitations, based on the direction the projects have taken and the intended audience.

Perhaps knowing a bit where I'm coming from (though there is *ALWAYS* considerable overlap between terminology) will help stop anyone from chugging the Haterade in this topic. I'm still not sure where the fanatacism comment came from, though. I wasn't even implicitly making a "USE TORQUE EVERYTHING ELSE SUCKS" comment. I wouldn't do that, regardless.

If you are looking for graphics, you'll need a competant programmer to help you interface nicely with just about any engine. If you use Max, Blitz3D has an excellent toolbox available (which Adrian has often attested to; if I used Max, I'd love to give it a go). But you'll need a competant programmer to make your game look beautiful and play well. The tools themselves may be nice, but to make the game (especially if you have to build the engine from the ground up), you'll still need a competant programmer. Torque's artpath is getting better (which is a great thing since it has long been an issue).

Source has a nice artpath with XSI, but unfortunately, you'll have to compensate with the license. Blitz3D has an excellent Max artpath, but you'll have to compromise with creating your engine to utilize the artwork. Torque provides excellent functionality and yet lacks some of the art features and physics that some desire. Everwhere there is compromise. It just depends on what you're willing to compromise.

#9 Well said David, that sums things up pretty nicely in my mind :)

I think one area where Torque has an advantage over all the others is Garage Games itself. The people that built garage games are industry veterans and have their foot deeply buried in the industry giving them a lot of credibility, and the ability to somewhat jump the gun and get the better games they publish in front of publishers and the media, people that wouldn't normally give a newbie indie team a chance.

Having your game written in torque and good enough to publish on multiple platforms, and does a good job demonstrating what their engine is capable of may possibly give you an advantage over your competitors. Often in this industry, who you know can make all the difference. It's still going to be a hard slog and require a lot of skill and luck at playing the marketing game. But I don't think any other low cost development solution out there at this kind of price can offer the same opportunities.

I may be wrong but I do feel there's a lot of added value that you won't find elsewhere. And creating a game is only half the game, getting it out there and making a success of it is at least half the work. And something most developers that like to hide away and make games aren't generaly good at.

#10 @ Matthew: I indeed sayd: not out of the box. I saw the snapshots you're talking about.
I understand Torque is suitable for almost everything, but not out of the box.
You say you saw various game genres developed with Torque, but when I look at the snapshots I see the same core everytime:
1st or 3rd camera view, sometimes also vehicles, firing weapons only, everytime with a different story and a different ambientation.
I saw 4 (not literally) projects only that differs from this "default" scheme: Orbz/MarbleBlast/RocketBowl (wich are similar however), the WIP flight simulator with tse, some puzzle games and some games using RTS starter kit. The rest of the games are almost the same.

@ David:
If you are really a programmer, you have a programming mind and whenever you see a problem (not only in computers) you're able to break up the problem in steps to perform to solve the issue. This said, I never claimed an API is an engine, neither a Library is a API.
I just said for what belongs to me Torque is not that particular, because being able to break up problems as I can and as far as I know, I always obtained better results than forcing myself to use the C++ source code, or following a not-fully-documented art pipeline, as well as trying to get something out of QuArK without using 3dgpai1 book's installer (wich is instead needed because configuration of QuArK for Torque seems to be not documented at all).
An engine is just a codebase wich controls something and perform something else, very basically speaking.
If you can do an engine in C++ you can do it in java also, as well as basic, assembler, python or whatever.
An engie just cares to receive input from peripherals, send output to video card and soundcard and eventually use some networking capabilityes.
Once you get this, you can build ground up until you're OK so that's what makes APIs, Libraryes and SDKs all suitable for this kind of work.
As I said earlyer, I'm just looking for stunning graphics and I don't care about the rest, because I'm able to solve problems in the simplest and most dynamic manner, so (at least by me) Torque is not the best, neither the only out there. Let's say if you can point me to a good graphic engine with affordable Physics integration for no more than $ 500 or so, I would go with it. About the fanaticism thing, is not the first time I see a reply of the kind "go with torque" to any "wich is better" question. When somebody asks a "wich is better" question, often omits the "to get this done" specification, so various people here is starting from the base mindset wich says "Torque, whenever and however!". OK, I'm getting in feeling with Torque too but I actually see differences between an engine and another. So in my first post in this topic I suggested all the 2D engines I know in order to let Josh decide by himself wich is better for his needs, instead of recommending only T2D.

About your final phrases: I can say I'm a competent programmer myself even if C++ is not my language, because I think about programming not as how to implement my solutions but as the solution itself. Once I get the solution I can translate it to almost every language, the proof is I programmed games with:
The games factory, Click & Play, Div 2 Games studio, 3D Game Studio, Torque (well it's WIP), Qasic, Python, C++ (text mode only), Commodore 64, ZX Spectrum, DarkBasic Pofessional, Blitz (but with the trial). Nothing commercial neither commerciable, but learned a lot.

Source was used for developing Half Life 2 and its cost is around $ 10k (!!!).

Bye, Thc.

#11 Cost wasn't the deciding factor for registering vocabulary. $100k is no different than free in terms of vocabulary. Actualization and articulation, yes. Vocabulary formalization, no. You didn't seem to be defining an engine per-se but a development paradigm; one which could be effectively articulated with an engine (as long as it had the requisite portions for your design methodology) a SDK (say, the DirectX SDK) or a API (which is often used synonymously with SDK), a library (SDL, which has expanded into both an API and a SDK in many ways), or a language. If you think of it hierarchially, an Engine often utilizes a Software Development Kit which includes a number of Application Programming Interfaces which are accessed through libraries. It's more of a series of indefinite circles with considerable overhang than a procedural list, though. It's just easier to represent it that way textually. And while groups themselves may have defining terms, there is no definite standard as to where one ends and the other begins (at least no recognized standard, as companies and groups will do what they want and term things as they desire).

On the technology note for a nice graphic engine (as long as you have a high-quality artist) with affordable physics integration, you should take a look at Irrlicht and ODE. The integration is nice, and I enjoy both engines. For network integration, check out TNL. It's a great networking library that can be tuned extremely nicely. There are three pieces of an engine for you, and three very nice ones, too. You might also like to check out Ogre as your renderer and the Nehe tutorials for OpenGL programming. They provide a lot of the basic stepping stones to get the eye-candy. The Nebula Device 2 is also a rather nice little engine with eye-candy. But it also depends on distribution point. If you're looking at a Mac release, you should probably look at Ogre with ODE and code in your artpath (the loaders for Irrlicht work well, though the complete engine hasn't been ported). Of course, looking at Canon and Tim Aste's artwork, TGE can do some amazing things if you have an artist who can do their research. Looking at the spellcasting particles being worked on makes me feel the same way, as does seeing the terrain and waterblocks in TSE.

There are limitations with every engine/sdk/api/library/language; you just need to figure out where they lie and accomodate for them or move on.

I'm still not sure where the fanatacism came from, though, since no one in the topic (unless posts were deleted or edited) had pushed the "USE TORQUE" mentality. Sure, it happens a lot. We've all seen it. Just like when someone talks about Irrlicht integration on the Blitz site. The common response is: "Why not just use Blitz!?" Well, because Irrlicht has an amazing amount of built-in functionality that would have to be built from scratch. It's not that it couldn't be done in Blitz (just as a competant programmer could take Torque and do anything given an infinite amount of time and resources). It's a not-so-subtle way of not re-inventing the wheel. I see the same attitude on just about every site I go to. But I hadn't seen it in this topic at all until you mentioned it, which was why it threw me for a loop.

As to being a competant programmer, I had no experience with your programming history. It seemed like it was an artist/designer track towards eye-candy rather than a tech-laden programmer's track. I didn't mean to insinuate that you weren't competant. I simply meant to emphasize that if you were looking for eye-candy, someone on your team would have to do it. If that's you: great. If it's not: you'll need to find someone. If you're a great programmer, you'll also need a stunning artist to provide the graphics you need. It works both ways.

#12

Quote:Source was used for developing Half Life 2 and its cost is around $ 10k (!!!).

Wow! That's a great deal! You sure you didn't miss a zero there? I've worked some with source (but the project was dropped by the publisher before it was even really started), source is awfully nice to work with (at least from an artists (as me) point of view) where torque can be slightly... ehm; Awkward, at times =).


And just to make everything clear, you're right in effect I suppose, but source wasn't really "used for developing half-life2", source IS half-life 2. Or well, the engine developed for half-life 2 in either case.

#13 "On the technology note for a nice graphic engine (as long as you have a high-quality artist) with affordable physics integration, you should take a look at Irrlicht and ODE. "

like i posted in my thread about crystal space, ive been looking into open source engines lately and I agree with David on the quality of irrlicht. honestly, it still doesnt compare to torque when it comes to performance, but it handles bsp environments pretty well. if youre a c++ programmer, the api is well documented and theres more than enough example material and docs to get you started.

if anyone is wondering why Im even researching open source engines since Ive been developing with torque lately i can respond with two words: software rendering. =)

#14 I have two words, too... Pixomatic and Mesa. ;)

I'd like to note that Torque is fully suitable for pretty much any genre game you want. It's been used for puzzle games, hunting games, RPGs, RTSes, MMORPG.. lots of stuff.

I don't think it's a reasonable complaint to say that Torque is not capable of other genres. We give the community a starter FPS, and most of them don't go beyond that. But that's like having a Ferrari, driving it only on the street, and then claiming that it's no better, nor any different than a skeezy old Honda, or a garbage truck, or a tractor, or a tow truck, because they all end up going the speed limit. You have to take it out to the race track to see a difference...

#15 *Perfect* analogy, Ben.

#16 Ok, in order:

David:
Well, maybe I misinterpreted your reply, but all the time I see people compare Torque with other engines and say the others are not engines.
There are engines, it depends on what the development needs are. Cost does matter, especially if (as me) you are a clerk and have to ask financements to realize a dream. I know what "engine" means but the missing circles can be done by the developer.
As I said earlyer, C++ is not my language at all, too much tricky sintax because of pointers and I really can't find anything written in C++ that doesn't use them. In addition, too much ways to do the same thing, this can be viewed as freedom of choice but is just a mess by me, trying to figure out what this library used rather than that. I'm keeping an eye on Irrlicht from version 7 and waiting for the "quality jump".
By now, some graphic things needs to be fixed (such as shadows and extending shaders support) and using Quake3 maps is forbidden for commercial usage.
I can't neither use it with C# or VB.NET because as far as I know there's no ODE for them.
Forget about the fanaticism thing, even if I'm still convinced about it I'm thinking you aren't the right person to point this at.

Magnus:
Yes, probably I miss a zero or more (lol).
Well, source is state-of-the-art as unreal engine 3, but they are too expensive. Thanks for pointing this out, however (I'm talking about "source IS HL2")

Ben:
Is not exactly as you say. I'm trying to make a beat'em'up out of TGE but it's done with firing weapons in mind, so the only choice the user could do is [firing weapons] or [no weapons at all], and even if there are some melee and hand to hand resources they're a bit messy.
In another environment type I would used something like:
the player is colliding with an enemy? -> cast a ray from the player going forward and check if the enemy is in front of the player.
Is it? Well, then is the player punching or kicking?
punching? -> Apply 1x damage to the enemy, let the enemy play the hurt animation.
kicking? -> Apply 2x damage and let the enemy play the kickhurt animation.

And with similar structures I would have built a beat'em up engine with the ability to punch and kick out almost everything.

Nothing personal, neither with you nor with GG in general, but Torque really is not general purpose. And I say this because Torque has a lot of stuff to manage FPS style games, with the addition of vehicles and the variant of 3rd person camera out of the box, but it misses the kind of commands needed to be really general purpose. And if it has them, they're not documented well or not at all, and I say this because I can't find commands useful for general 3D programming, such as determine the current animation frame, have general input management (as looking for a particular keypress in order to do something, but starting from a precise moment and not having this defined before the game actually starts), and so on. These are some small examples, but Torque is too much high level to claim it's really general purpose. Too much automagic put in action genres. Well, out of the box speaking. Surely modding the source is possible to do anything, but if I really need to mod the source there could be at least some ort of disclaimer saying:"Torque is general purpose as long as you mod the source, otherwise you'll have to master the inner Torque's secrets in order to get something else than an FPS, racing or RTS game (well, maybe you can still make a puzzle game) so be prepared for a 2 or 3 years of Toque full immersion.".
Side note: hunting games are firing weaponed games, puzzle games requires just triggers and doors well managed, RPGs include various genres so it's yet to see what kind of RPG you're talking about, RTS does come out from GG official starter kit but is not included with Torque purchase and still requires source modding. About MMORPG I have my doubts, but I'm opened to news...

Bye, thc.

#17

Quote:the player is colliding with an enemy? -> cast a ray from the player going forward and check if the enemy is in front of the player.
Is it? Well, then is the player punching or kicking?
punching? -> Apply 1x damage to the enemy, let the enemy play the hurt animation.
kicking? -> Apply 2x damage and let the enemy play the kickhurt animation.

Uhm... you have the source right there in front of you. You can do exactly what you described, no problems.

#18 See, I consider DarkBasic and Blitz Research BASIC derivatives to be languages rather than engines, which I believe is where the confusion between implicit definitions of "engine" is happening in our shared vocabulary. Plus, I tend to write walls of text which can easily be obscured. Sometimes people think that the more they write, the clearer it seems, but that's often not the case (especially when writing off the top of your head like I do). Meaning tends to get obscured. But as languages, they are oriented towards game development just as VB was originally oriented towards creating applications with easy database integration. It has since evolved into a much more feature-rich language (and people were doing fun things with it even before that; DirectX in VB was a fan project for quite some time).

And I understand that realistically speaking, price is an issue, but as to the discussion of what defines an engine and engine functionality, it was not. And, as a side note, the Q3 map format is not a legal problem. Utilizing Radiant to create maps is. I believe that Newton, Novodex, and Tokamak have VB bindings. You might look into those physics engines.

#19 WOW, I thought VERGE died years ago. Hehe, nice to see it's still kicking around after all these years(heck, it now has some networking features to boot). It's primarily geared towards making 16bit console style RPG's, though you can do other types of games with it. The scripting language is based on C.

GameMaker is pretty good, though you'll want to dip into the actual scripting language for it pretty early on. Click and build game building gets rather limiting fast.

Glest doesn't really belong on that list, it's a 3d engine.

#20 "As I said earlyer, C++ is not my language at all, too much tricky sintax because of pointers and I really can't find anything written in C++ that doesn't use them.

thc you really shouldnt let a bit of foreign syntax prevent you from engaging in a language as pervasive as C. pointers arent hard at all. the hardest thing about them is understanding why theyre useful. all you need to do is recognize how the structures are passed. one function will always return a pointer and another function will take that same type of pointer as a parameter. its no different from passing and returning other kinds of datatypes.