Grit game engine - prefered particle editor?
polycounter lvl 8
Hi,
Were working on a game engine called Grit, with the goal of creating an open source streaming world game with lots of GTA ellements. Our coder just implemented deferred shading and will start on a particle system soon. I opened this topic to ask what you guys would prefer:
What are your experiences in the most pleasant particle editor?
Were working on a game engine called Grit, with the goal of creating an open source streaming world game with lots of GTA ellements. Our coder just implemented deferred shading and will start on a particle system soon. I opened this topic to ask what you guys would prefer:
- A dedicated particle editor exe
- Ingame particle editing with some sort of GUI
- Any other options?
What are your experiences in the most pleasant particle editor?
Replies
Abstract it. Why make an engine if you're just going to copy the rest of the engines that can not compete with the engines of today that abstract everything away from the runtime?
As an open source engine, we must have abstracted tools so different people can get into development of what they want to work on - without having to sift through the currently 100k+ lines of code (without dependencies) just to work on a particle editor. It needs to be abstract like this for modularity and the ability for people to carve out their own little niche in the community.
Put tools in tools, like every other modern engine. We started this engine to clone the workflow of GTA modding. GTA has no in-built editors.
THANK YOU. I'm glad I'm not the only one that's tired of this whole "super-massive single program that does everything and is hard to learn" thing that Unity and UDK are doing.
But, I actually like UDK and Unity's system. It works well, they are both very intuitive engines. And, you can see what the particle system looks like in-game. So you don't work blindfolded. I'm currently working with an external particle system at work, and it's a pain in the ass, because you constantly need to get everything in-game before seeing the real results. It may look awesome in the particle viewer, and total shit in-game. And vice-versa.
My most pleasant experiences so far was actually xml-based, hitting reload with left hand, writing numbers with the right. Lacked lots of parameters, sure but it forced you to work methodically, blocking out a desired effect.
Each have their advantages and weaknesses of course, and it really depends on your line of work, but having worked both ways, given the choice, I'd pick a proper engine/editor combo like UDK with barely any hesitation.
the question is whether to build tools into the render window and use in-game gui for tools or to do stand alone tools LIKE udk and unity but not "all encompassing".
So, in game fugly GUIs or windows with X's on them and real file menus.
So far, particle editing is looking like it can really only be realistically done in the engine, but at least there isn't a whole lot to particle editing.
Grit Game Engine uses Max, for example, as the editor. 1 generic unit = 1 meter, exactly like Rockstar and GTA/RDR/Bully, etc. Whatever you export from max goes to the same place in the engine that it was in in max, basically. Just like rockstar.
The question is about whether we do this (random images, to show the difference between in game and a real editor):
http://www.bigworldtech.com/images/particle_3.jpg
or this:
http://www.scotthconner.com/img/particle_editor.png
As you can see niether of these options are anything like UDK. If we were going to do a UDK or Unity, we might as well use those. Unity would be the smart choice for tiny teams without a budget, UDK for teams with money to spend and time to blow.
This engine is basically going to be/already is like "stripping the map out of GTA and putting in your own, to make any kind of game on the planet, rdr, bully, any of these games are possible because rockstar took the time to make GTA first" (as in, they made an engine that does anything the world does that you would want to reproduce in a video game, and now, just by being selective about what they use, they can make any kind of game they want) - so the big question is, do all of our tools get done IN the game engine render gui, or does it get done in small little apps on the side.
So far, the answer is looking to be "both" because for one thing a particle editor probably really ought to be done in the game itself, and there is more than just particle editors one could use.
Handling editors, sky cycle editors, etc.
If you were to compare to it UDK or unity, it'd be stand alone kismet, stand alone material editor, stand alone SMALL apps that a community could change who works on them and add to the fun whenever, without one huge nasty thing like udk. (unity is pretty sleek, but it's still a one-editor solution)
We ask about it here because we not only respect and enjoy your input, but we want you to use our engine one day xD
Actually, we got a lot of room for leaders who want to take a hold of this opportunity with us :x
I say put the editor into it's own window with it's own GUI (though similar to the main editor program), that way users who have multiple screens can move it from one screen to another with ease.
Seeing things update in context is priceless
I actually have to agree with this. I use an xml-based system at work. And yeah, it doesn't have nearly the same amount of parameters as UDK/Unity's system, but it gets the job done quickly and efficiently if you don't need something too complex. Granted, like mentioned above, it sometimes looks different once it is actually in-game.