Happy Birthday IndieZen!

Submit your own resources!

Oliver Rendelmann - DerR   (Dec 13, 2007 at 10:44 GMT)

Hello! Good luck with Eclipse and your project. :) In course of a student software project I have to work on an advanced Eclipse plug-in myself... it tends to give you lots of headaches sometimes. :)

Tony Richards   (Dec 13, 2007 at 15:18 GMT)

@Oliver

Really? I've never had any problems with them and I've written and I maintain quite a few Eclipse plug-ins. I love how Eclipse will deploy a second copy of Eclipse in a separate Java VM to help debug... that's awesome!

@Others

To the people or person who rated my blog entry a one star, would you mind at least posting what you didn't like about it?

You insult me with a one star, at least let me know who you are and why you're insulting me.... or if you have some real criticism, bring it on. I've got thick skin :P

@GG - Could you change it so that people can't post a rating anonymously?
Edited on Dec 13, 2007 15:47 GMT

Ross Pawley   (Dec 13, 2007 at 16:19 GMT)   Resource Rating: 5

@Tony, sounds like an excellent idea. Are you planning to make it work along side some of the tools available? What part(s) of the pipeline will it cover?

Tony Richards   (Dec 13, 2007 at 16:43 GMT)

@Ross

To make it work along side some of the existing tools will only take import / export plugins.... again, not perfect integration. I've already written a couple of importers and exporters to support 3d model file formats (.OBJ and COLLADA), but I plan to have .DTS and a few other formats soon. Again, this doesn't really facilitate true integration but it's a necessary step until we have a complete toolchain.

If I have source code of a given tool (and a license that allows me to do it) then I'll convert whatever I can. My hands are tied in some cases since applications like Blender and Gimp are covered with GPL license and I don't have the source code to Constructor (but maybe GG would like to participate... who knows?)

The parts of the pipleline I hope to cover includes everything... from tools that help organize game concepts all the way to installation, patching and CRM / technical support required by games (and of course everything in-between).

3d modeling, animation, textures, BSP / brush based editing, terrain generation and editing, folliage and tree creation, world editing, script editing (Torque Script, Python, Lua and others are already done), script debugging, AI middleware, MMO Middleware... the list goes on and on.

If you're interested in creating any of these types of tools, I would be happy to help with the framework and provide whatever assistance I can in creating the tools.

One thing to remember... the framework is free and open source with a very friendly license (ZLib), but whatever tools you create don't have to be free or open source. You are free to do whatever you want with the plugins you create, including sell them, give them away, keep them for your own personal use, etc.

Ross Pawley   (Dec 13, 2007 at 18:43 GMT)   Resource Rating: 5

Hrm...well I think it's a good idea to get a more integrated, easy to use toolchain. However, I don't know that trying to take rewriting the wheel to furthest possible extreme is really a good idea. In this case it's more like rewriting the wheel, the axle, the engine and the body of the car. The problem I see isn't really one of having to import/export, or that the tools available don't work well, but merely that they're very loosely bound to eachother.

Besides, writing a whole 3d modeler from scratch, reinventing script debugging...etc. seems like a whole heap of work when merely integrating the tools available to a high degree and polishing the work flow would be less effort and more benefit. I like the idea that an app can do certain things *really* well, rather than having a monolithic piece of software that does everything under the sun poorly(not to say your tools would work poorly, just that something very specific to a certain need will always be better than something that tries to fulfill every need).

Also, I don't see AI middleware as something really appealing. Most of the time you get what? Some sort of navigation code. You still have to have a programmer tweak what you get, and even then it won't be but probably 10% of what you really need for your game. It's very game specific IMO.

Not to bash on your idea or anything, I think it has merit, but I think you should rethink your approach some.

Tony Richards   (Dec 13, 2007 at 19:25 GMT)

@Ross

Thanks for your comments.

Quote:

---

when merely integrating the tools available to a high degree and polishing the work flow would be less effort and more benefit

---

Been there, done that and it stinks... although it's a solution, it's not a good solution. This is definately a better solution.

First, let me make it very clear that I am not reinventing script debugging, etc. For script editing and debugging I'm utilizing Eclipse plugins that already exist today. I may have to modify them a bit to make sure they are using the same interpreter that the embeded game engine is using, but 90% (or more) of that has already been done and is currently being maintained by some awesome developers.

I'm also not planning on writing a whole 3d modeler from scratch.

Sure, I'm going to be writing portions of one, but it will be using an open framework so that plugins can be written to enhance it.

Think of it kinda like Blender or Torque Constructor where you can add plugins and/or scripts to enhance the functionality, except split it out so that the framework can be hosted in Eclipse and Constructor itself even becomes a plugin. You could write a new lighting model for a game engine and use it to light your models in Constructor... voila, WYSIWYG editing except you're not stuck with the current hard-coded lighting model. Granted, Constructor and TGE-A have awesome lighting models, but what if you wanted something slightly different?

Nobody can think of everything. Nobody can implement everything. That's why I'm proposing this as a collaborative project. Together we can think of everything necessary for making an awesome framework and individually we can create (or refactor existing code) to fit within this framework.

The IP resulting from the collaboration will be owned by the entire community, not one individual person or company.

The plugins we create will be our own to do with as we please.

Quote:

---

monolithic piece of software that does everything under the sun poorly

---

The plugin system solves this problem.... it's not one huge monolithic piece of software. It's a nice core set of frameworks and a bunch of plugins that interoperate seamlessly.

You're not forced to create a model in a 3d modeling application, export it to ZBrush, add some details, export it back to your modeling application, add some animations, etc.

Instead, you have a basic 3d model editing plugin with plugins that can modify the data, add animation, texture it, add shaders, have a built-in GLSL or HLSL shader editor and then view it with your game engine's rendering engine all in one application.

This sounds like a whole lot of work, and I'm not going to try to fool anyone... it is going to be a whole lot of work. It's going to take several months just to get some of the most basic things finished and it will be several years before it'll be useful enough to be able to use it as your sole game creation toolchain.

But, once it gets to that point it will be a huge revolutionary leap in indie game development.

If you're only interested in making games (which a lot of people here are here for just that purpose) then other than some feedback, there's probably not much you can do to help. I don't want to distract you from what you're doing either... continue with your game development and make some great games.

On the other hand, there are quite a few people that hang around at Garage Games and GameDev.net that are interested in making tools and tool-chains. That's who I'm trying to recruit to help with this project.

You know who you are... :P

The guy that makes L3DT, some of the Blender people, the MMO middleware creators, the guy that wrote the Huge Terrain Creator, the people involved with creating Torque Constructor... people like that. You'll still be able to sell your software (or open source it if you want).

The only difference will be that everything we create will work together and we'll all benefit from it.

Ross Pawley   (Dec 13, 2007 at 20:22 GMT)   Resource Rating: 5

Well, my point is that there are some very good tools out there that simply don't work well *together*. It seems very counter-productive to completely scrap what's there, because of the fact that a lot of it doesn't work well together. I'm definitely interested in a better integrated toolchain, but I'd be seriously reluctant to throw away, for instance, Torsion, in favor of Eclipse script editing (I like Eclipse, but Java is pretty crap for GUI apps, and the ones that are good (Eclipse *is* good) tend to cause Java to take up several hundred MB of RAM for no good reason...Torsion is ~30MB and I know some of the scriptsense stuff would be very sluggish in Java, or having to interact with Java based GUI (since you mentioned plugins would be in C++)).

I also realize you didn't intend writing a whole 3d modeling app from scratch, but it still brings up the point: why write pieces of one from scratch anyway? Torsion and Blender are both apps that benefit greatly from their tight focus. If Torsion tried to be a 3d modeling program it would be a much worse script IDE for it. And vice versa for Blender.

Tony Richards   (Dec 13, 2007 at 21:11 GMT)

Nice debate... I'm enjoying this conversation. Hopefully you're interested in continuing.

Granted, Eclipse is a bit bloated... I have three versions running right now with different sets of plugins. One is quite bloated and is taking up about 150 MB of RAM and took about 30 seconds to load. Another is the Eclipse Process Framework Composer and it takes just a touch under 100 MB. Another one is a stripped down version with very few plugins and it's taking about 60 MB.

Quite likely if I spent a couple of hours on it I could create a Rich Client Platform application with nothing but a Torque Script editor and I bet it would take between 30 and 60 MB of RAM, but it would be significantly more flexible (i.e. built in SVN / CVS support, etc)

If Blender and Torsion were both plugins in Eclipse and if they were coded with the mindset of the rest of Eclipse (i.e. tons of extension points to allow for customization) then they would be so very much better than what they are today.

Blender wouldn't have to use it's internal text editor for editing Python scripts... it could use Eclipse's Python development and debugging plugins which are tons better.

If Torsion had been created as a plugin inside of Eclipse then it would have nearly seemlessly and automatically gain the benefits of having built-in SVN / CVS source control among many other things that Eclipse provides as extensions and extension-points.

The problem is that Blender is trying to be more than just one thing and Torsion should be trying to be more than it is today.... I really wish it supported some sort of extensibility and some sort of version control integration. Not just embedded SVN... what if I wanted to use Perforce?

The problem is the teams creating these applications are too small to try to be everything for everyone.

Let the small teams concentrate one what they do best, but let it integrate seamlessly with everything else.

The guys creating the Subversion plugin can concetrate on making the best version control system while the Torque script plugin can become the best at that, yet they both can still work well together.

Blender doesn't integrate with any version control system at all... wouldn't that be nice if it did, though?

Guess what? The 3d modeling tool that I've already started creating does support SVN, CVS, Perforce, etc... how much coding did I have to do to get it to work? Well, other than making this a plugin in Eclipse (which was actually a lot easier than trying to make it a standalone application), I didn't have to write a single line of code to integrate with all of the currently supported version control systems in Eclipse.

It just works {tm}

Version control is just one of many examples of things that Eclipse gives you pretty much for free. Internationalization and localization, spell checking, scripting with pretty much any modern scripting language known to man... and the list goes on and on.

Will Torsion ever support all of this? Will Blender? I seriously doubt it.

Ross Pawley   (Dec 13, 2007 at 22:03 GMT)   Resource Rating: 5

Sure, I love a good debate.

The problem I see is that, yes, you may have a script editor and/or debugger in Eclipse. The problem arises in that to have all the features that even Torsion does, it has to work with the Eclipse GUI, which as you say, is bloated. Also, Torsion allows you to look at the explorer context menu, so nothing stops you from using Perforce, if it has context menu integration (and in that way, it certainly supports version control). Also, I'm curious what parts of it you think need to be extensible? More integration with the engine?

Blender using its own text editor seems annoying, but I think a solution there would be to write a plugin for it that could interface into your Eclipse, so you could do "edit in Eclipse" or something and open it right there on the spot, rather than having a new 3d modeling app to learn.

You said previously that it would be possible to do this closed-source. I and James (at Sickhead) are working on some possible cool features for Torsion, so if you're willing and that is in fact the case, you could let me take a look at what you have and what sort of thing the plugin system requires and *maybe* we could do a Torsion plugin. Only problem I see with that is Torsion uses wxWidgets, which would sort of suborn the Eclipse GUI (which I'm not much of a fan of anyway, since Java GUI is pretty bad IMO).

My email is in my profile, go ahead and drop me a line.
Edited on Dec 13, 2007 22:08 GMT

Tony Richards   (Dec 13, 2007 at 23:50 GMT)

It would be a far stretch to ask Sickhead Games to completely abandon the wxWidgets implementation... I wouldn't want to see that happen.

But, what if the GUI and the non-gui portions were separated. I know this sounds a little weird since Torsion is mostly a GUI, but I can explain this in a little more detail via e-mail or in person. (I used to live in Dallas and all of my family is still there, so I visit from time to time... we should meet and discuss this. I think my next visit is next month if you're interested.)

If the GUI and parsing / colorization (and everything else) were split into well defined interfaces, you could pretty easily create a plugin that could operate under different environments.

What if Torsion were an Eclipse plugin and it implemented some extensions for code injection, and then what if Torque's mission editor and GUI editors were also Eclipse plugins and they utilized those extensions.

You could then edit your missions and your GUI's with a combination of a WYSIWYG editor and with a cool syntax colorized editor simultaneously inside of a single application. The extensions and extension points would loosely couple the plugins so that if one or the other weren't installed then you could still use the WYSIWYG or the text based editing without relying on the other half.

Take that a step further... when I use Blender to export animations and models, I have to for the most part manually maintain the corresponding Torque scripts. What if the exporters could be hooked up with code generators to automatically generate the appropriate code... that would be cool, especially if the code generation part were flexible and/or scriptable so engine modifications could be taken into consideration.

You could still have a standalone Torsion that uses wxWidgets, or you could have the Java GUI with the Torsion backend for integration... and you could even use Torque's widgets and have a Torsion editor inside the game engine.

The back-end plugin would be the same... it would just be the front-end GUI that would be different.

And no, I'm not asking you to maintain three different widget sets... wxWidgets, Eclipse SWT and Torque widgets are already being maintained by their respective developers. You might have to maintain a bit of code that's redundant on each of the platforms, but look at what you'd get in return.

Now, I've taken for granted that Torque could support the proposed plugin system and that's probably a far stretch since I've not seen what the Torque 2 plugin system can do yet.

This is also kind of a small view on the project as a whole... if we make everything a plugin, from script interpreters, editors, rendering engines, etc and all of the sudden game developers could use Ogre3d as a render engine, Atlas 2 as the terrain engine, Torque Script as the scripting engine, ODE as a physics system and Torsion as a script editor.

Frameworks allow people to pick and choose the best / most appropriate plugin / component in each area.

I know, that probably doesn't sound very appealing to you... Torsion would rely on people choosing Torque Script over Python, Lua or even Java.

This open frameworks concept does foster a whole lot more competition... in the end, everyone wins, though. Garage Games would be forced to improve the Torque Scripting language if they wanted to compete (or abandon it altogether and concentrate on other areas). Ogre3d and the addon developers would be forced to improve their terrain and terrain editing systems in order to compete with Garage Games's Legacy and Atlas 2 systems and their awesome terrain editor. And eventually, maybe that would force L3DT to improve it's terrain editing system in order to keep up.... or possibly L3DT could concentrate on procedural generation and someone else (GG maybe?) could write a cool editor.

The possibilities are endless.

In short, there would be no more vendor lock-in and there would be a substantial number of innovations as a result of everyone trying harder, concentrating on what they do best and competing in areas where competition has historically been ignored.

Novack   (Dec 14, 2007 at 02:35 GMT)   Resource Rating: 5

I think part of the problem, is the fear of great part of the non-java developers to the Eclipse world. Much of what is said in general -and what was said here- comes from the the little use (AND understanding) of a tool like Eclipse, and the philosophy it represents to the tool-chain development.

It is not only one of the better (AND industry proven) editors today, but also the idea is not only to reinvent the wheel, but also to integrate.

What Tony says about one tool, using the others best, is the whole idea behind the Eclipse principles.

One of my first questions when I first saw Codeweaver and Torsion was "why the hell this guys dont used Eclipse as the IDE?". The answer was very similar to what Ross is saying now: "ugly" gui, very fat memory footprint, and "buggy" plugin system.

I think those are the classic expressions to say: "Yes, maybe that would be a better path, but I use this other tools/language for development, and I need to finish this project quickly". I think is a valid point, to a first version, but maybe you should really reconsider that for a second or third.

Tony says that Torsion is mostly a GUI. Well, I have to say, as a GUI, Torsion is one of the less flexible editors Ive seen. The script sense is really rough (almost useless), and I cannot even configure a keyboard shortcut! Yes, is low memory, but other than debugging, any other editor is better.

Besides, the ambition should be something more like a real IDE, not a colored notepad with debugging. No, is not the GUI, the real Power of Torsion are his amazing Debugging capabilities. That been said, that could fit perfectly on an Eclipse plugin, to use its almost endless editor capacities!


Edit: re-reading my post, I noticed that some parts could sound offensive. Rather than edit it, I prefer to leave it alone, and say: my only intention is to continue the good debate. If you Ross feel offended, I apologize, wasnt really my intention.
Edited on Dec 14, 2007 02:41 GMT

Ross Pawley   (Dec 14, 2007 at 03:15 GMT)   Resource Rating: 5

Bleh, it killed my post off after I spent a good half hour writing a detailed reply. Suffice it to say, I'm not convinced Eclipse is really the miracle cure here.

@Novack, no offense taken. I'm not sure why you think the scriptsense in Torsion sucks though, I find it extremely useful.

Novack   (Dec 14, 2007 at 03:46 GMT)   Resource Rating: 5

LOL - Ross, sorry to hear about that reply, its always good to see different perspectives. And thank you for your comprehension about some parts of my previous post.

About the scriptsense, as is not the core of the debate here, but I mentioned it first, I will try to be concise saying that, after briefly working with Java language on Eclipse and NetBeans, I saw the potential of an intellisense/snippeting system; so I didnt wanna mean that in Torsion it is unuseful, but -in comparison- is more like a toy: needs more depth to turn into a truly useful tool; that been said, as-is is better than nothing.

I perfeclty understand that Torsion is a recent project (in comparison), and is maintained by so much less people... but thats exactly, why I think you should take it in mind to manage (now or in some future) the IDE approach, beyond the current GUI approach.

That way, the time your team invest on learn the Eclipse architecture, is a one-time investment, that will revenue back later, when you see the Eclipse evolve by itself, while you concentrate on others totally different aspects of the project.

Ross Pawley   (Dec 14, 2007 at 04:09 GMT)   Resource Rating: 5

Well, I've tried to use Eclipse. I was writing up a game that needed to be run in Linux pretty much exclusively (due to Cairo, pretty much, which can be built on Win, but it's a pain and would have been even slower), I had a choice between Eclipse, and something like KDevelop. I found Eclipse to be rather buggy, slow, and have an unacceptable memory footprint, even on Linux (I've tried it in Windows for another reason and it seemed worse). It had some nice features, but between the crashing and the not being able to open a single dialog because it took several minutes (on a pretty darn fast machine, no less, with 2GB of RAM) I ended up choosing KDevelop which I've found to be *very* nice. Not Visual Studio 200X nice, but with some work it could be there. Eclipse was a nightmare by comparison. Maybe that's just me, but it seems like any time I use a Java based GUI app, the same set of issues constantly rear their ugly head (sluggishness, general poor performance and huge memory footprint, instability (not always on this one)). Thus I am extremely wary of Eclipse.

Not to mention, yeah it may be cut down to a good 30MB, but the JVM takes up 30-60MB when it's completely idle anyway. I have a feeling that with any 2-3 of the discussed plugins opened up, it could easily exceed 300MB.

Tony Richards   (Dec 14, 2007 at 04:49 GMT)

If you haven't tried the latest 3.3 version, you should really try it... before this latest version I really hated it... you're right; it'd crash all of the time (especially if you were coding C++ and not Java) and overall it was pretty bad.

Now I love it... no crashes ever since I installed 3.3. The C development toolkit is more for C and kinda stinks for C++, but it's definitely getting better... not a Visual Studio killer yet, but I expect it will be soon.

It is still a little sluggish but it's dramatically better than it used to be.

There's really no comparison of Visual Studio for C++ compared to Eclipse's Java... I've been training a new Java guy at work (right out of college). I started him on Eclipse doing some Java coding for awhile, then I switched him over to Visual Studio on a C++ project and his first comment was "Hey, I thought this was an IDE and more than just a text editor!"

I nearly died laughing, but he's right... Eclipse provides so many more tools than Visual Studio.

What's more is IndieZen only uses Java for basic GUI... the hard core algorithms for modeling, etc are all C++ so it shouldn't be sluggish at all.

I'm sorry about your lost post... I hate it when that happens. I've lost so many posts that I've learned my lesson. I end up copy / pasting (and saving!) to a text file before posting it on GG's website.

Novack   (Dec 14, 2007 at 04:55 GMT)   Resource Rating: 5

Yes, Yes! I made some comment like that one Tony!

@Ross: LOL (again), Ive been there. Believe me, the only way to "tame" Eclipse, is to stay, and play, to take time with it.

And yes, it has a great memory footprint (do not count linux on that, it manage memory wide different than Windows, doesnt count in the same way), but you know what? its a matter of get use to it. Today, a developer workstation cannot have less than 1GB. The GUI is Java, but you forgot that with the everyday use, and lets be honest, today its the same f**** thing, where you note the diff?

The stability issues are weird, but it depends on the distribution, the version... In this point, the con, is the pro (and vice-versa), cause when you get what you want working, then thats all, like linux, you can make your own distribution. OR NOT, you could just distribute a plugin, and recommend X Eclipse version.

And again, lets be honest, on complex tools, sometimes can happen that something fail and you have to touch something by hand; that could be not doable when the time is against you, but to set a game develpment environment, I think it is perfectly aceptable (when, and IF it happen).

Now I will be honest, and tell you my story with it: the first time I used Eclipse, my time was running out (with a friend we got a deal to develop an administrative system), but we take the risk hoping that if anything go wrong, we'll always could make it on Delphi on 1/10 the time :D

We take it as an adventure, and in the process we discover the Java Universe (place where I hope to never ever return to :D :P) Is a different way of view and make things, I will not argue on that, nor I will explain you things that you know for sure, but the things is, that in the process I could understand the approach they pick to make things happen.

Sure, Eclipse can be an elephant;
sure, can be dificult to setup;
sure -even when you dont visually notice it- its a crappy Java GUI;
sure, you have that good damn JavaVM running at -what you think it is a- whim.

But at the end, when, and if, you can get over it, you will fall in love. And is a love you never forget (to the point of punch like a bastard other very good tools ;)

Ross Pawley   (Dec 14, 2007 at 17:11 GMT)   Resource Rating: 5

Admittedly, I was trying to use Eclipse for C++, and compared to VS2005 or later, it looks like a buggy text editor. I had tried a later version that had a Ruby plugin, and found it semi-okay, but the mem footprint is just too absurd. I like to keep an IDE open while I do other things, and if it's taking damn near a 1/4th of my total RAM (2GB usually) I find that seriously unacceptable.

@Tony, the plugins would be in C++, but the GUI would still be Java, which is typically where all the sluggishness is introduced in Java GUI apps anyway. I've seen command line Java apps which are perfectly fine, but as soon as they get a single button on screen, be prepared to wait a couple of minutes for each redraw (okay, I'm prone to hyperbole, but meh).

Daniel Staub   (Dec 21, 2007 at 15:59 GMT)

@Tony
This is all very interesting (And a bit over my head) but I have a few questions.

I understand your frustration with the lack of integration in the Game Development process but don't you think that part of the problem is that you are trying to go the job of more then one person?

2D Art
3D Art
Level Design
Engine Programming
Game Scripting
Project Management
Sound

These are all different jobs. They require different skillsets and different tools.
I would think that working with the different tool creators to improve the Import / Export process to standardized formats would be faster, much less work, and help a lot more people.

Do you think you could get the makers of ZBrush to create a ZBrush plugin for your framework?
If not do you think that you (Or anyone else in the short term) could write a ZBrush-like plugin that would do the job as well?

For the most part the established tools are fantastic (If expensive in some cases), reinventing them just doesn't make much sense.

Dan

Tony Richards   (Dec 21, 2007 at 17:59 GMT)

In small teams, sometimes one must wear multiple hats, but honestly I've never had to wear all of those hats you just mentioned. Fractured Universe has a core team of about six people wearing multiple hats.

These jobs do require different skills, sometimes require different people and always require different tools, but there's no reason why these tools can't work together seamlessly.

Not one person can play all of these roles all of the time and expect to do a great job at it. You need a team of people working well together.

The same is true of tools... not one tool can do all of these jobs and expect to do them all well. You need a group of tools working well together.

The same is true of the tool developers. Not a single company can do all of this alone and expect great results.... but a collaboration of developers working on the framework, then going back to their dens and creating plugins for the framework... now that will work well... everyone can concentrate on what they do best.

I'm not saying what we have today cannot be used to get the job done, I'm saying there's a better way.


ZBrush is awesome... but it's slow and clunky.

Can you use it to create 100 completely different models with five different levels of detail, fully skinned, animated, UV mapped, textured, shaded and exported into your game engine?

How much time do you think it would take one person to do it and how much would you end up spending on tools?

Next year or early 2009 will see IndieZen finished.

If all goes well, in 2010 I'll be publishing a massive multiplayer game, and five core games and possibly a few casual games utilizing fewer than 20 people and spending under $20,000 on software, tools and tool development to get it done.

Lets see a AAA game studio, or even an existing Indie game studio accomplish that using the existing tools.

Yes, it does make sense to re-invent the tools... especially if Indies really want to compete with the bigger game studios.

You must be a member and be logged in to either append comments or rate this resource.

Home | Products | Solutions | Downloads | Support | Search | About Us
Copyright © GarageGames.com 2000 - 2008 All Rights Reserved