Take Two...
by Tony Richards · 11/13/2008 (8:40 am) · 11 comments
Hrm... the one-star rating on my previous blog shows that I didn't make my point very well.
Let me try once more...
Click Take Two! Action!
Zen Engine doesn't replace Torque or any other game engine... it augments them and provides you with more choices and with those choices come true freedom for Indies.
Freedom to innovate, freedom to choose, freedom to share.
So, why am I here on the GG website blogging about Zen Engine? Well, since Zen Engine is open source, I'm recruiting... if you're a good C++ programmer, contact me if you're interested in contributing.... there are several areas of code that need improvements and some good old fashioned programmer TLC.
Also, I'm hoping to get a few more people understanding exactly what Zen Engine is all about... why did I make it and what problem does it solve?
Zen Engine solves everything I've ever complained about when using Torque... but the solution doesn't mean you have to give up using Torque.
Zen Engine is middleware that can be easily integrated with Torque to augment its capabilities... seemlessly and painlessly.
It uses plugins, extension points and extensions to allow you to customize it without having to dig into the core code and make modifications. Of course, you're not limited or restricted from making code changes... the point is that you don't have to!
No longer will you need to wade through a bunch of resources on this website and hoping somehow to cobble together a game engine that fits your needs... plugins are much better than cobbling.
Zen Engine is all about freedom, and true Freedom doesn't come until we have choices... and Zen Engine provides the balance and the technology to allow you to choose.
Torque (or at least the next version of TGEA) lets you choose between FMOD vs OpenAL and OpenGL vs DirectX.... that's fantatic! But is it all the choices you want?
Wouldn't you rather have every component be a choice? Slaughter those sacred cows! You don't have to be stuck with (insert something you don't like about Torque here)... but you also don't have to throw the baby out with the bath water.
Ogre has a vastly superior rendering engine over Torque, but it's not a full game engine so most people can't use it for making a game. Can you just drop it into Torque? Yes, you can!
Lua, Python, Ruby and JavaScript are vastly superior languages over Torque Script. But, can you simply drop them into Torque? Yes, you can!
How about MySQL, PostgresQL and SQLite integration? Can you integrate those into Torque without changing a single line of code? I mean full integration including missions, datablock caching, persistent worlds, etc? Yes, you can!
How about networking? Garage Games' claim to fame is their fantastic network, but some of these new libraries coming out can support peer to peer networking with hundreds of players in an FPS or even an MMO game without a server! But, can you drop it into Torque with minimal code changes?
Well yes, you can!
And the list goes on and on... Rules Engines, AI Engines, Forest Rendering middleware...
Zen Engine doesn't replace the need to purchase Torque if you want to integrate it with Torque. You still need to purchase a license for TGE / TGEA / TGB from Garage Games.
The same goes for FMOD, RakNet and several other libraries that are integrated into Zen Engine. It's your choice and you only have to pay for the licenses of the libraries you choose to use for your custom game engine.
And since the Zen Engine frameworks are free and open source, you get all of these extensions and plugins that work with Torque... free!
Can you build a custom game engine tailored specifically for your game without writing a single line of code? Yes... you can!
Happy Torquing... or whatever... it's your choice! Isn't freedom great?
Let me try once more...
Click Take Two! Action!
Zen Engine doesn't replace Torque or any other game engine... it augments them and provides you with more choices and with those choices come true freedom for Indies.
Freedom to innovate, freedom to choose, freedom to share.
So, why am I here on the GG website blogging about Zen Engine? Well, since Zen Engine is open source, I'm recruiting... if you're a good C++ programmer, contact me if you're interested in contributing.... there are several areas of code that need improvements and some good old fashioned programmer TLC.
Also, I'm hoping to get a few more people understanding exactly what Zen Engine is all about... why did I make it and what problem does it solve?
Zen Engine solves everything I've ever complained about when using Torque... but the solution doesn't mean you have to give up using Torque.
Zen Engine is middleware that can be easily integrated with Torque to augment its capabilities... seemlessly and painlessly.
It uses plugins, extension points and extensions to allow you to customize it without having to dig into the core code and make modifications. Of course, you're not limited or restricted from making code changes... the point is that you don't have to!
No longer will you need to wade through a bunch of resources on this website and hoping somehow to cobble together a game engine that fits your needs... plugins are much better than cobbling.
Zen Engine is all about freedom, and true Freedom doesn't come until we have choices... and Zen Engine provides the balance and the technology to allow you to choose.
Torque (or at least the next version of TGEA) lets you choose between FMOD vs OpenAL and OpenGL vs DirectX.... that's fantatic! But is it all the choices you want?
Wouldn't you rather have every component be a choice? Slaughter those sacred cows! You don't have to be stuck with (insert something you don't like about Torque here)... but you also don't have to throw the baby out with the bath water.
Ogre has a vastly superior rendering engine over Torque, but it's not a full game engine so most people can't use it for making a game. Can you just drop it into Torque? Yes, you can!
Lua, Python, Ruby and JavaScript are vastly superior languages over Torque Script. But, can you simply drop them into Torque? Yes, you can!
How about MySQL, PostgresQL and SQLite integration? Can you integrate those into Torque without changing a single line of code? I mean full integration including missions, datablock caching, persistent worlds, etc? Yes, you can!
How about networking? Garage Games' claim to fame is their fantastic network, but some of these new libraries coming out can support peer to peer networking with hundreds of players in an FPS or even an MMO game without a server! But, can you drop it into Torque with minimal code changes?
Well yes, you can!
And the list goes on and on... Rules Engines, AI Engines, Forest Rendering middleware...
Zen Engine doesn't replace the need to purchase Torque if you want to integrate it with Torque. You still need to purchase a license for TGE / TGEA / TGB from Garage Games.
The same goes for FMOD, RakNet and several other libraries that are integrated into Zen Engine. It's your choice and you only have to pay for the licenses of the libraries you choose to use for your custom game engine.
And since the Zen Engine frameworks are free and open source, you get all of these extensions and plugins that work with Torque... free!
Can you build a custom game engine tailored specifically for your game without writing a single line of code? Yes... you can!
Happy Torquing... or whatever... it's your choice! Isn't freedom great?
About the author
I am the founder of IndieZen.org, a website dedicated to the Indie 2.0 Revolution where a number of Indie game development studios and individuals collaborate and share a suite of custom built open source game development tools and middleware.
#2
11/13/2008 (8:51 am)
Im interested! 
#3
11/13/2008 (8:51 am)
Sounds great! And what about physic engine?
#4
@Everyone else... thanks for the rating bumps :P I'm glad someone is out there that appreciates all of our hard work and the thousands of hours of effort we've put into this project.
Thanks!
11/13/2008 (9:04 am)
@Taras - Ah, thanks for reminding me... we do have physics plugins and ZNewton is mostly complete whereas our ZPhysX plugin still needs a lot of work. Hopefully in the coming months we'll also have plugins for ODE and some of the other fantastic physics engines out there.@Everyone else... thanks for the rating bumps :P I'm glad someone is out there that appreciates all of our hard work and the thousands of hours of effort we've put into this project.
Thanks!
#5
11/13/2008 (9:34 am)
Thanks for the plug! I don't know if we are "making it big"!, but I'd say we definitely took a "step back" on purpose in order to make it small. Good luck with Zen, I'm a huge fan of the various open source licensing models, I think they can be really powerful (technically, and monetarily) with the right projects and right situations. :) 
#6
I think a few insights on the background would be great, considering the scope of the ZenEgnine.
I would also want to know your opinion on this: the abstraction layers are fantastic when possible, but for instance, TNL works so beautifully in Torque, because it is integrated at the core of the engine, to the point that you cant program a line of code without thinking in client-server terms... So yes, the ideal case would be to keep full powered features, while counting with a fully modular framework, but what are the framework solutions behind putting toguether a few libs/engines not created to work like that?
And one more question:
All in all, I admire your work on the project, and hope to keep reading news about it.
11/13/2008 (11:28 am)
I always liked your project, since the first time I read about it on your .plans. My fears though, are quite simple: the project seems to have grew out of proportion, an awesome piece of software, an engeneering work worth of any game developer dreams... an still your speech keeps beeing "Im just making it, along with a few volunteers, wanna join?".I think a few insights on the background would be great, considering the scope of the ZenEgnine.
I would also want to know your opinion on this: the abstraction layers are fantastic when possible, but for instance, TNL works so beautifully in Torque, because it is integrated at the core of the engine, to the point that you cant program a line of code without thinking in client-server terms... So yes, the ideal case would be to keep full powered features, while counting with a fully modular framework, but what are the framework solutions behind putting toguether a few libs/engines not created to work like that?
And one more question:
Quote:some of these new libraries coming out can support peer to peer networking with hundreds of players in an FPS or even an MMO game without a server!REALLY??
All in all, I admire your work on the project, and hope to keep reading news about it.
#7
There are other libraries like this as well. RakNet for instance can be used for peer to peer networking and it's a rather reasonable price too ($100?)
Of all the code we're integrating with the framework, I haven't met anything that wasn't fairly easy to integrate with the framework. Some of the integration (such as the scripting) took a whole lot of thought and design, but even that ended up falling into place rather nicely.
Originally Torque was the toughest to integrate, but Stephen Zepp said something the other day that let me realize what I was doing wrong, and that opened the doors for the ZGarage plugin to be made with only minimal effort.
In TGEA, the only code that I call "poorly designed because you can't use it and you have to modify it" is in the T3D folder. Use it to see how not write code, and use as an example of how the rest of the engine can be utilized... then throw the T3D folder away and never go back... it's not part of TGEA... it's just one example of how you can use TGEA.
It's a poor example in my opinion because the code in the T3D folder is designed in an old style OO design...
New design methodology teaches us to "compose" objects instead of using class inheritance... it also teaches us to use inversion of control. These and a few other modern design patterns and practices are extremely important.
If you take that approach and rewrite the code in the T3D folder using modern design patterns and practices, and you write it to the needs of your game then you'll be a much happier Torque user.... MUCH MUCH happier Torque user.
I can't say that enough... it should be in the "getting started" manual for Torque... if it was then we'd be seeing a whole lot more people finishing games with TGEA than the small handful that succeed at it today.
Yes, it does seem that way... dream big, then scale back and implement what you can now and tackle the rest later is my philosophy.
If you don't understand that philosophy, Jeff Tunnell does a great job of explaining it in his The Art of Backing Off article.
Recently we switched to quasi-monthly releases following a rather agile and transparent development methodology. This has helped a lot.
It doesn't really matter how large the scope of the project becomes, as long as we manage it and continue growing incrementally and in small chunks.
Of everything that's finished today, you can use it today... A lot of the code is in several projects that have already been completed and are currently in production. Done, complete, finished. Using Zen software.
In a few weeks with our next release, that too will be usable, with more features. The following months we'll finish and release even more.
I have a fairly loose project plan that stretches into the next five years, but the bulk of the Zen Engine code is done, and the small amount that remains will be complete before the end of the year.
If you take a look at the Zen Open Source Software roadmap you can see where we've been and where we're going and when we'll get there... at least to some approximation. Anything further out than two to three months generally changes as we learn more about where we can go with what we've already finished.
Thanks for your comments!
11/13/2008 (1:58 pm)
@Novack - I'm not sure if you're being facetious or not with the "REALLY??" question, but if you're interested, check out Relay for just one example... I met and spoke with David, the founder of Relay, at the last IMGDC and he's a fantastically sharp guy. If he's not done yet then I'd bet he's close.There are other libraries like this as well. RakNet for instance can be used for peer to peer networking and it's a rather reasonable price too ($100?)
Quote:but what are the framework solutions behind putting toguether a few libs/engines not created to work like that?
Of all the code we're integrating with the framework, I haven't met anything that wasn't fairly easy to integrate with the framework. Some of the integration (such as the scripting) took a whole lot of thought and design, but even that ended up falling into place rather nicely.
Originally Torque was the toughest to integrate, but Stephen Zepp said something the other day that let me realize what I was doing wrong, and that opened the doors for the ZGarage plugin to be made with only minimal effort.
In TGEA, the only code that I call "poorly designed because you can't use it and you have to modify it" is in the T3D folder. Use it to see how not write code, and use as an example of how the rest of the engine can be utilized... then throw the T3D folder away and never go back... it's not part of TGEA... it's just one example of how you can use TGEA.
It's a poor example in my opinion because the code in the T3D folder is designed in an old style OO design...
New design methodology teaches us to "compose" objects instead of using class inheritance... it also teaches us to use inversion of control. These and a few other modern design patterns and practices are extremely important.
If you take that approach and rewrite the code in the T3D folder using modern design patterns and practices, and you write it to the needs of your game then you'll be a much happier Torque user.... MUCH MUCH happier Torque user.
I can't say that enough... it should be in the "getting started" manual for Torque... if it was then we'd be seeing a whole lot more people finishing games with TGEA than the small handful that succeed at it today.
Quote:the project seems to have grew out of proportion
Yes, it does seem that way... dream big, then scale back and implement what you can now and tackle the rest later is my philosophy.
If you don't understand that philosophy, Jeff Tunnell does a great job of explaining it in his The Art of Backing Off article.
Recently we switched to quasi-monthly releases following a rather agile and transparent development methodology. This has helped a lot.
It doesn't really matter how large the scope of the project becomes, as long as we manage it and continue growing incrementally and in small chunks.
Of everything that's finished today, you can use it today... A lot of the code is in several projects that have already been completed and are currently in production. Done, complete, finished. Using Zen software.
In a few weeks with our next release, that too will be usable, with more features. The following months we'll finish and release even more.
I have a fairly loose project plan that stretches into the next five years, but the bulk of the Zen Engine code is done, and the small amount that remains will be complete before the end of the year.
If you take a look at the Zen Open Source Software roadmap you can see where we've been and where we're going and when we'll get there... at least to some approximation. Anything further out than two to three months generally changes as we learn more about where we can go with what we've already finished.
Thanks for your comments!
#8
For the rest, your comments are really interesting, and appreciated. I understand a bit of design patterns, but never heard of "Inversion of control", I'll take a look at that.
Also liked your comments on the T3D code folder, that was not only insightful on the Zen project, but also Torque itself.
On a side note, I think what you mention as your "implement what you can now and tackle the rest later" philosophy (which is very good indeed), has not necesarily something to do with the "backing off" iterative design that Jeff Tunnel mentions on his last post: I think in Jeff's case, only the final design is what matters, which is not the same case as "dream big". I rather found the former more like a philosophy, and the second just a design process :)
Keep us informed on the Zen Framework please.
11/13/2008 (2:58 pm)
@Tony, no, I didnt mean to be harsh with the "REALLY?", in fact the total capitalization was an error, I didnt noticed it, due to the BB codes and such. I feel surprised about p2p on FPSs with houndreds of players beeing a reality, I thought it was something not possible, and it seems to me that something like that could change the face of the multiplayer gamming.For the rest, your comments are really interesting, and appreciated. I understand a bit of design patterns, but never heard of "Inversion of control", I'll take a look at that.
Also liked your comments on the T3D code folder, that was not only insightful on the Zen project, but also Torque itself.
On a side note, I think what you mention as your "implement what you can now and tackle the rest later" philosophy (which is very good indeed), has not necesarily something to do with the "backing off" iterative design that Jeff Tunnel mentions on his last post: I think in Jeff's case, only the final design is what matters, which is not the same case as "dream big". I rather found the former more like a philosophy, and the second just a design process :)
Keep us informed on the Zen Framework please.
#9
At any rate, you understood what I meant ;-)
11/13/2008 (3:10 pm)
@Novack - Yup, you're completely right about that article... I guess I read into it that he'd eventually tackle the "big" stuff.At any rate, you understood what I meant ;-)
#10
Oops... the hat distracted me while I was voting!
11/14/2008 (11:47 am)
Quote:Hrm... the one-star rating on my previous blog shows that I didn't make my point very well.
Oops... the hat distracted me while I was voting!
#11
That's my overall impression about Torque tech.
HALLELUIJAH!! Despite my lack of belief, there is a God after all... Hope GG guys are reading this too.
11/30/2008 (11:24 am)
Quote:It's a poor example in my opinion because the code in the T3D folder is designed in an old style OO design...
That's my overall impression about Torque tech.
Quote:New design methodology teaches us to "compose" objects instead of using class inheritance... it also teaches us to use inversion of control. These and a few other modern design patterns and practices are extremely important.
HALLELUIJAH!! Despite my lack of belief, there is a God after all... Hope GG guys are reading this too.
Torque Owner Taylor Petrick