SamaGames looking for team members

Hi there everyone,

I have been working in the game industry for the 15 years.
I have worked for EA, Cyan, UBI and for the last few years Square. Last week Square started the unannounced layoffs.
Sadly I was one of them.
It may have been my fault I was pushing for a sequel that they were never going to do. Honestly I was thinking of leaving, I feel the industry is heading in the wrong direction due to details I can't go into.

I have given it a lot of thought and want to start a Design Group. I want to start giving players the games they want and beg for. For free of course.

The mission of SamaGames will start as remaking classic as true to the original as possible.
After a few titles to see hows things go we do our first squeal.

I am looking to with the Snes classic Shadowrun.
and if all goes well maybe even get a second team going for
Final Fantasy 6.

Anyway this is getting long so hit me back and lets get things started

As what?


And how to make money if not by selling the games?
And if you think that it is not needed to make any money with it, I wonder how long you expect the developement to take when the team just works on it in their spare time for like 1 or 2 hours a day?


Why should I then play your game if it is anyways the same as the original one?


I think this is a typo and you mean "sequel"?
What makes you think that a market with Call of Duty 6, Crysis 2, Portal 2, Medal of Honor 7, Doodle jump 4, Battlefield 3 (isn´t it actually 6 or something?), Angry birds 6, F.E.A.R 3, Minecraft and Total War 6 a sequel of a ripoff of some "classic" game? While I really think that there where great games with some great gameplay I would prefer to see their mechanics taken to a whole new level or of course some completely new gameplay in a new game instead of the hundred thousands sequel.
And if you think that there is nothing, that hasn´t been done before, you could at least try to make something existing better in a new game.

And as you are planning to release the games for free, you will pay the licensing of the remake from your own wallet to the company that laid you off?

By the way, are you going to work the games with Gamestudio, or with other engine?

Also as a point of intrest, what Slin said, it's just like that. The sequels sell only if the game gets really popular.

Sorry I've been gone the last day or so,
Look I should have been more clear I don't plan on doing this legally
I have been in this game for a long time and know that a little nostalgia is what will save the industry My reason for Shadowrun is personnel I was an Intern at Data east when it was being made. and it holds a deep place in my heart.

Have you some site or portfolio ?

You think that the industry which is growing year on year needs saving?

yep, it does need saving, hate the direction of mainstream game development now, theres been a dramatic reduction in the amounts of games / quality games being made, i just see alot of flaws with the industry, some developers do a great job, mainly the big guys. Basically the game industry as reached the point where either youre one of the big guys or noone cares about your game, sure its far from dead but i think it was alot better in past recent years

Do you know what people would do for a new chrono trigger a Stargate game or a remake of simons quest or metroid.
The idea of Sama isn't to make huge amounts of cash that's were everything went wrong to begin with. The point is to show the high ups what the players really want.

Will you join Darkinferno?

There is really good indie games coming , just seek for ome on Steam !
For example Torchligh 2 , Trine 2 will be great for indie market.
Big games are great, and can't be done by a little team :
Mass effect 3 , BorderLands 2 , BattleField 3 , Guild Wars 2 ,
Oblivion sequel, Zelda sequel etc ...
A a lot of people wait for this great prodcution games



The only problem is when big companies make bad games, and buy little companies doing good games ...
Like Microsoft that baugh Rare, it has just killed this Studio.
But hopefully , there is some little studios doing great : Retro Studio, Grass Hopper etc ...

-----------------

And don't be so sure about what players want, some are big fans of Warcraft, other is COD multiplayer ...
Not all players are big fans of RPG , Stragate or Metroid !!!
Even more i'm sure perhaps it would lot more people that would like FF7 remake than Chrono Chross or other ...
And i don't like Stragate so ...

Well the question is more what is the game that is on your heart and that personnaly you want to remake ??

that's easy the snes Shadowrun

It's first time i heard of this game on Snes, not so well known.

The problem fo making an exact copy, it's the copy rights !

Even more it's a total waste , if the remake would be a great success with improved 3D graphics, gameplay etc ... like some other remakes, you won't be able to sell it !

If you make it for free, i'm not sure you'll find people ready to put lot of their free time making textures, characters, animations etc ... for free just like that.

Even for real projects destined to be selled perhaps, it's hard to find people motivated, or they begin and stop because they find other pririties in their life etc ...

So ... well, perhaps make it yourself alone , the best way to not be disappointed ??

They are lonewolves sometimes doing better than companies :
Sonic remake

Why do you choose A8 engine if you are a pure 3D artist ?
some other engines are better suited for 3D artists ??

All that is really strange ? And you could present some portfollio ? if you are really an artist working in Industry
you should indeed have one ??

isn't that the shadowrun is like the father of the original fallout?

also, ratchet, you hearing about a gmae first time does not mean it's not so well known.

@Sama: Instead of doing 1:1 remakes, i think its better to look what worked and what didnt work for those games, and build your own game(even if heavily inspired by one). This way you may even get some cash(maybe a faithfully created game, for some euro), and that might be a more promissing way to build up a team.

EDIT: even if your game isnt like the one its inspired by, gamers may still think "Oh..this reminds me of >insert game here>. HAvent played something like this for a long time." etc etc. A Familiar feeling is always a plus, your own story anotherone. redoing the same might be some risk(in 2 ways: Gamers not linking, Companys going mad about copyright)

Greets
Rackscha

i strongly agree with Rackscha, i hate game remakes that mirror the games, well i like seeing them but i dont like the idea of making them because personally as Rackscha says, i think its better to take the game idea and do your own twists on it so you can produce a commercial game, instead of remaking zelda for example, why not develop an own character just as loveable and try to create an own franchise .. i guess noone thinkgs like this anymore

I am going to have to agree that it is quite strange that someone with industry experience would choose this game engine. I have seen one or 2 decent games made with this engine in 11 years. If your an experienced artist Sama then I would love to see your portfolio and also advise trying Unity as its a free engine with no royalties. Still odd that you would even post here. I have been in the Industry for 4 years and rarely ever do anything related to Gstudio anymore as Conitec does very little to upgrade their products.

I disagree with both of you. Ratchet, I do think lone-wolf pure artists aren't going to get very far with GS. But this is the Jobs Offered forum, and he's looking for a team. He's not trying to make something all by his lonesome.

Gamesaint, I'm surprised at you, after you recently posted Supercan, and you must be aware of Dejobaan's work. Less amazing stuff comes out of GS only because it has less users. Unity is much better marketed, and much better known. GS lacks cross-platform support, but besides that is extremely capable. Sama's looking in the right place!

Sama, may I suggest you joining someone else's team first. A little freelance work, or even contributing artwork to the community, will gain you some reputation within the community, give us a better understanding of you, and get a more positive response from other users who are available to work.

Jibb

The fact is that the A8 just is extremely behind most other engines. Supercan is made with A7 and Shade C which isnt something that comes with the acknex engine, therefore to get those kind of graphics its relying on a 3rd party plugin. Come on people face it this engine lacks alot of things that would make it extremely nice and why bother paying for it when there are cheaper and even free products I can use? I have spent tons of money on this engine and I dont see it as a waste but I dont see it as an investment. Unless you have seasoned and extremely talented people then making a game with A8 is just not something I would want to try ever again.

Shade-C isn't a plugin. It's just a whole bunch of .c files and shaders. Everything it does, you can do in SED. BoH_Havoc just makes it easier by writing a whole bunch of good stuff himself.

Everyone's scared of shaders, but most won't even try them.

Anyone relatively competent with Lite-C can be writing their own normal mapping shader with dynamic lights and other tweaks of their own within a few hours with the official shader workshops. That's the first thing I did when I got A7 Commercial years ago and decided if I had an engine that supported shaders and I couldn't write them, I was wasting my money.

So how is it behind?

Jibb

But the realitiy is not like you mention it here. I worked with a lot of engines, indie and professional ones. And when I talked with the makers of the Vision3d engine about their documentation I learned, that they even split documentation into artist and programmers documentation, just because all their customers work that way. There are people responsible for different areas of a game. And only a few projects bring their own shader programmer. Many projects will not touch shaders at all and will rely on the delivered technology. That is by the way the reason why they spend so much money on an engine. They want ready-to-use technology. They want to save time and want to finish a game. It does not make much sense to finish the engine, especially in the today's market where you often have to make smaller games with a small budget.

Actually you are right, that it is very easy to make a normal mapping shader in many engines. There are visual shader editors in C4, Unity (as a third party plugin), in Vision3d and in UDK. So it is just connecting a couple of nodes in the right order. But later it might be harder if you desire to let them interact with light-maps or directional lightmaps or other effects. Some engines have all that integrated into the nodes, others need some manual work, especially when you have a cross-platform project.

So it is not always a big problem. Often artists can do it on their own. But when it really needs a bunch of customized shaders, it will distract you for months, maybe even years, except you have a dedicated shader programmer in the team. But suggesting that a lone wolf should do all this on his own is probably not a way to succeed.

It does not make much sense to finish the engine, especially in the today's market where you often have to make smaller games with a small budget.

Indeed, for people who's goal is to finish a game and sell it , even a casual game, they can't spend programming tools or learn shaders , specially when there is lot lot of stuff onto HUD, menus panels , molde,s textures, animations etc ...

I like to use standard shaders (normal map, toon shader, , water ,refraction, HDR etc ...) , i just want theses standard
to be available, but i'm not interested at all to program shaders !
So yes some times a visual shader editor is better for non
pure programmers !

Actually, the reality is exactly how I mentioned it, because the shader workshop holds you hand and takes you step-by-step through writing a normal mapping shader. Want to extend that with dynamic lights? The manual gives you a function you can copy into your code.

Except for a few exceptional cases, shaders don't take much time at all. I do everything in KarBOOM, and the shaders have had very little impact on development -- only a few days altogether, including rewrites as my needs change, and I've been working on this since September last year (although with some interference from university).

Between the shader workshops, the manual's great examples, and the way materials work and can be strung together in Gamestudio, it truly is very easy to learn to write shaders -- more so than in other engines.

Unity provides automatic dynamic lighting, for example, and because of that shaders have to be written in an unusual way, and the result uses unnecessary passes (although I don't know how it works with the new deferred renderer). It provides a global shadow system, but last I checked that was just CSM, which I've written a short tutorial for on my website.

I'm not suggesting teams need shader programmers, I'm saying if you have a Lite-C programmer with Commercial or Pro, you should already have a shader programmer.

Jibb

Again, it is way easier to drag a few nodes to a surface and to connect them. I just did it in Vision3d and I did it in C4 and UDK. There is a simple lighting node with connectors for Diffuse, Normal, SpecularColor, SpecExponent, SpecMultiplier, Opacity and AmbientColor. And I can drag TextureNodes or Constants or whatever to it.

I create shaders in minutes there and I dont have to care about the number of lights, fog, static or dynamic lighting. The lighting node contains all this. There are some general flags to activate alpha testing as an example.

But in the end an artist can create powerful shaders that way. And there is no exponential explosion of shaders for every number of lights.

And a workshop is even not necessary. It is very intuitive especially since most artists already know such node-editors from their 3d rendering applications.

Here are some images of how it works in Lightwave and in UDK. There is acutally no difference between realtime and still-rendering applications. It just works. And that is how most projects do their work, how most applications are built. So I said that this is how reality is today.

I guess it's a matter of preference -- programmer versus artist. I'd no sooner choose to click together a shader over writing one than click together a game rather than make something original.

Node-based is great for simple materials. Engines that provide such a system make it easy to meet some industry standards. But what is one to do when they want a multi-texture shader where some layers cast some shadows on others, some layers have true reflections, and so on?

Writing one's own shaders is good for performance, as well. Even for a more standard multi-texture shader, if only two layers need a specular map, I'll write a shader that only uses a spec map for those two layers.

Even the simple stuff I do differently every time for different projects. Maybe in one project I have an AO map, which will only affect ambient lighting, but in another project I can't be bothered and I bake AO into the diffuse texture. Or I might hard-code some hemispheric ambient lighting -- very little performance cost, but it can really add some shape to areas in shadow. These are simple, intuitive, artistic tweaks that aren't all going to be doable in a node-based editor.

I wouldn't start a project in another engine without learning to write my own shaders in that engine. Custom-made shaders get a better performance:prettiness ratio.

As it turns out, I also create shaders in minutes. And then I can spend hours tweaking them if I need to, adding things and changing things, and see the changes updated in real-time. Code is easy to reuse by modifying default.fx: I might have my own fog function that uses a cube-map rather than a single colour to get a good-looking atmospheric scattering effect in a sunset -- I'd write the function once and from then on call "niceFog(pos)" in any shader that uses it.

Jibb

But the difference is: Your shader will be very special, working on a certain amount of lights and on one platform only. The abstract node based way supports different platforms.

Besides that it is not only a programmer vs. artist point of view like you mentioned. The Vision engine as an example also has a dedicated low level shader editor aimed to programmers with a good shader code editor (with 3 pages for global settings of the library, vertex and pixel shader). There are pannels forthe shader library files of the engine, panels for global shader properties, enlisted effect hierarchies and a real-time preview of course.

Besides that they recommend to also load shaders from artists into this low level editor later for optimizations. So it is not an artist vs. programmers story, it is often a story of collaboration.

Anyway, most projects especially indie projects will not create many custom shaders on their own. All the basic shaders are already included (yes, terrain shaders as well). And there are good reasons for that.

If more people would realize how important shaders are, this would most probably change.
The problem is that most think that shaders are just for some eye candy stuff and forget/don´t know that they actually are an important part of the rendering pipeline and are needed to see anything at all.
The power of shaders mostly comes by writing many very specialized shaders doing just exactly what they need to do, instead of just few master shaders slowing things down by doing something without effect.
In my opinion every project needs someone able to program custom shaders, which btw is something artists usually are not good at with node based editors as they tend to make things too complex . At least that is my experience so far.

This might be true for absolute beginners, but even without any shder writing I am able to select a material without spec and without normal mapping as an example to render faster.

I would agree with you when it comes to mobile devices. But the engines I know also come with many dedicated shaders for each mobile platform. So it is already possible to select only the desired effect and not a master overkill shader.

As an example there is a normal mapping shader for iOS that has a fixed constant lighting position (one light only) to speed rendering up.

Besides that I am not sure what kind of "artists" you know of. But the ones I am in contact with all have a programming background and know for sure about performance issues.

What do you mean "one platform"? The shader will usually work on any Shader Model 2.0 or higher card. If Gamestudio supported Macs the shader will probably be written in Cg instead of HLSL, which is virtually the same thing except it works with OpenGL and DirectX.You were talking about how much easier it is to make shaders with node editors; I'm saying for someone like me it's actually easier to write them. I will always choose to write a shader in a few dozen lines -- less if I re-use stuff I've written before -- rather than use a node editor that's either too limited to do what I want, or too convoluted to be intuitive. Of course it's often a matter of collaboration when a team has enough personnel to do so, but that's just changing the topic.

No one is expected to be able to use Gamestudio without Lite-C. Why do people avoid HLSL like the plague? Shaders are IMO the easiest part of programming for these reasons:
1. They are short. In order to perform well, shaders are generally only a few dozen lines. The programmer will spend only a few minutes before they can see the effects of what they're doing, and from there they can make changes and see the changes as they're made in real-time.
2. They're simple. Until you start doing really fancy stuff, you probably won't touch loops, and you'll rarely use branches.
3. They are visual. Rather than a path-finding algorithm that needs to be tested under all sorts of circumstances, or movement algorithms that'll often fail in very specific cases, shaders will either look right, or look wrong. And it doesn't take much to make a scene look fantastic.
4. HLSL is intuitive. Forget vec_add and the like. Just add, multiply, subtract, divide with simple operators. Most functions work this way, too. For example: light.rgb += ambient.rgb; adds the corresponding components together. colour.rgb = colour.brg; swaps around colour channels.

IMO the lack of a visual shader editor is a hindrance only to those with no programming experience. I can only imagine how poor KarBOOM's performance would be if its shaders were put together in a node-editor and used the built-in effects of Unity, for example.

Jibb

That is your personal view and most developers see it exactly the other way around.

And what I mean with one platform: When working with a node editor I dont care about DirectX, OpenGL, HLSL, CG and so on. My algorithm works on all these platforms. Basically shaders are nothing like that, a couple of vertex and pixel operations and I dont see why a node based shader should have such a big performance difference. If that would be true, no professional engine would use it. UDK / Unreal as an example is very fast that way. So actually, without any testings I would not claim something like that.

There is for sure a difference, but I would not overestimate it hat much. I read such arguments often. C4 programmers as an example defend their C++ language at all costs. They always tell it is the best, fastest and whatever. But in reality I saw games programmed in Java as an example running big FPS worlds with huge terrains and interiors (Chrome as an example). Often people are too much focused on their tools instead on the final product that could be done with other tools as well.

But HLSL and Cg aren't platforms. They're languages. The only platforms (shader-wise) are DirectX and OpenGL -- HLSL only works on DirectX, which doesn't matter because so does Gamestudio; Cg works on both. One written shader will run on everything.
You should learn how to write shaders, then. Because I can make the claims I've made. The performance difference isn't big at all, depending on how you're willing to limit yourself (as I'll explain at the end of the post).
We've had FPS games since the early 90s. The graphics stuff is still done on hardware in OpenGL, so such an example says nothing about whether or not Java can replace C++ for game development, and as soon as the Java programmers try to push boundaries they'll find themselves going back to C++. It's a completely different scenario. Besides, what's that about people being too focused on the tools rather than the final product? The final product, whatever it is, can be achieved with Gamestudio -- Isn't the whole point of this discussion was whether or not Gamestudio is visually behind?

In terms of performance between node-based shaders and written shaders -- there'll probably be no difference between the exact same shader, but node based shaders are restrictive, and I don't care about built in effects at all. The only claims I made to a big performance difference was that KarBOOM would perform poorly if I tried to achieve the same thing with node editors and "industry standard" effects. And it is true:

How many games feature particle shadows? How many node editors will let you do that? Most shadow-mapping systems will use multiple views and depth-maps -- mine uses one view and a standard RGBA bmap that the particles also get rendered into for almost no extra cost. The whole playable field is one quad with a very unusual multi-texturing shader. The mix-map (or whatever one calls it) is generated by a series of post-processing effects based on the level data. The explosions are each a single sprite with a very fast shader generating the effect procedurally -- normals, internal lighting, sun-light, density, etc.

Jibb

You still did not get my point:

If a 16-year old ambitious boy starts to develop a game, he will learn a node based shader editor much faster than HLSL. He does not need to know the math behind it, how to format a variable, how to define a scalar, a vector, whatever. He does not know about what mathematical operation is faster compared to another and so on. He connects some nodes. And that is easier to understand. Because of that, they dont like to learn another programming language. There are alternatives.

Besides that small casual games like Carboom have a limited audience. It does not make sense to learn different languages and to write so much shaders. I know that you did not learn it in a few days. You gathered a lot of deep knowledge, hints and experience over years.
But to earn money with such a game, you have to finish it in a few months, just because such games bring only a couple of thousand dollars. But if such a game will be released on Windows only, it will probably sell even worse. It could make sense on mobile phones though.

Because of that you will not find many casual developers writing their own shaders. The other ones like Slin will find a dedicated job sooner or later in a game company and will write shader only there.

This tells us a lot. It will keep hard to convince hobby developers to write their own shader. You tried that a lot in the past. But when you convince somebody to write them and he will dive deep into this world, he will probably not finish a game but become a shader expert. If such an expert is willing to look into more than only Gamestudio. If he is similar to Slin, who looked into Irrlicht, Unity or iOS, then he has a a good chance to find a job in the industry.

This is acutally how the reality works.

I was a 16-year old ambitious boy once, learning code, not visual editors. It's not hard to follow up a 25-chapter Lite-C workshop with a 7-chapter shader workshop -- especially since the first 4 chapters work well on their own (they were originally written to end there) and are what I learned with. I was stoked to find I could write shaders in the exact same environment I produced everything else with.
Shaders in Gamestudio are written in HLSL -- that's the industry standard for writing shaders in DirectX (along with Cg which is identical). The engine generally doesn't matter when it comes to writing shaders -- some are weird and have proprietary means to produce shaders, but they'll usually include options for HLSL or Cg.

If someone really wants a node-based editor, it wouldn't be hard to produce one. Make a user request or something and list the kind of nodes you want. I'm sure you'll find someone interested in making one.

Jibb

Again, while defending your position you always miss my points. I understand you perfectly and I also started as a programmer. I learned programming languages very fast and loved to code.

But this is not what I am talking about. When creating a game that earns you only a couple thousand dollars, you have to speed developing at every corner. So it is better to use ready-to-use shaders and to use tools that are fast and responsive, deliver real-time feedback and publish to different platforms (not only Windows, even when your CG=HLSL definition says otherwise, the entire product often has to be ported).

Also a shader is not the same on another rendering hardware, especially when you switch to consoles or mobile devices. I know that from the Vision manuals, that there are some special conditions when you release a product to the Wii, iOS or other platforms.

So what is your point? That Sama should use Unity? Or UDK?

As a Gamestudio user developing a game (between studying at university) that has consumed no more than a few days of shader programming over 8 months of game development (and I don't mean a few days of cumulative hours, I mean a few days during which I spent some time on shaders), I don't see why you're talking about platform portability and speedy development.

Next time you tell me I missed your point, please follow that up with a summary of what your point actually is. It'd make things easier for both of us.

Jibb

Wow. Talk about hijacking a thread to argue a point. Why not let Sama recruit for his game(s)?

What!? And not get the final say!?

No, fair enough. This definitely got out of hand. Sorry, Sama.

Jibb

lol, agreed.

I've been watching this thread more since the hijacking than when it had first started... (and before anyone points out the obvious, I know it's now got more posts!)

Yes, you are right. Sorry for hijacking. But if you still missed the point I will summarize it for you and I will give you a little outlook in the end:

I really believe that everything you wrote works fine for you. And I am sure that people like you, who love to play around with shaders from scratch will agree with you. I would do as well if that would be my focus.

But I saw you trying to convince new users like Sama all the time to write their own shaders. And that is fine. But often it will not happen. There are several reasons for it. Most users need to write shaders only once per project and it is not the top priority. They will not learn every hint and trick. A workshop does not teach them the background of 3d lighting theory, matrix manipulation, variable types and much more. Even when they successfully wrote their own shader, probably the workshop shader with only a little adjustments, then they will continue on their project and forget about that very fast. And next time they have to start from scratch again. So I doubt that they write shaders in minutes, even when that works for you.

Another reason is that there are 2 kind of beginners: Some want to make a small realistic project. They dont want to write excessive graphics features. They never care about these shaders. The other ones are dreamers and want to have a modern up-to-date project. And they dream of great shadows, post-processing, HDR, DOF SSAO and even global illumination. The workshop will not teach them how to write that and they will not accomplish something like that in minutes. But they might see that some technology offers this right at the beginning.

So what is it all about? Basically: Most users will not write the graphical effects they dream of as fast as you said. And they dont want to write another normal mapping shader. They expect something old like that as the basics already included. They dream of something more advanced and will probably not accomplish it.

If you are honest, you will see that exactly this happens around us. The more advanced shader developers like Hummel, BohHavoc, HeelX and Slin also did not make such great shaders only from a workshop. They learned alot from Nvidia or from PDF research documents. They learned much more than only HLSL. The programming language is always the smallest issue, the knowledge behind the algorithms, the theory and the optimization strategies are the real asset, that has to be learned over time. And you often picture it, as if they can get all this in a few hours.
But the point I wanted to make is that many users dont want to start a journey over months or years without progressing on the real game.

Another fact you brought up is, that it would be easy to write a node-based editor for Gamestudio. I dont know how long you have been a Gamestudio user, but I remember that there was an official project like that. There was a module-based shader editor. I was even able to test the beta version. It never saw the release day. Maybe it is not that easy.

But on the other hand, this would be a great product. I know from the sales figures (e.g. from the Unity Asset Store) that tools like this sell much better than model packs. I know people who just wrote a framework for an iOS engine and they quit their day job and live only from that. But this also depends on the amount of engine users. I have no figures how many active users develop with GS.

matrix, and vector math is a bitch.

I agree with Frank and btw: I offered jcl to write a node based editor, not only for shaders but also for an entire pipeline (setting up render targets and such stuff). But he refused. And I think I understand why. You can create advanced rendering frameworks with GS but eventually it lacks of engine internal optimisations. It simply doesnt make much sense. Acknex is thought to be an engine for small projects like casual games, simple shooters/RPGs or prototypes and jcl want to keep that and thats fine imo.

I can confirm this. I was working with two people on a sci-fi project, but we had to cancel it two weeks ago. We were using shaders for nearly all surfaces and gamestudio simply couldn't work with that with a good frame-rate. Support told us that we couldn't to that with Gamestudio. We tested a bigger scene also using shaders on all surfaces in Unity and it worked at more than 100 fps.

What? A shader on every object, blocks and entities, and multiple post processing shaders work fine for me (above 300fps).

Eventually depends on the complexity of the shaders you are using. The forward lighting shaders you find on the wiki are the hell if you use them extensively.
There is no nativ deferred lighting support in GS.

as far as i know, the current example shaders are nice to have, but their performance is..not so good.