Hi All,

An issue was recently submitted to the GitHub Issues Tracker and classified as a bug, which you can read more about here:

https://github.com/TheGameCreators/GameGuruRepo/issues/555

Issue 555 relates to adding shadows for flashlights and for dynamic lights in the scene. After some conversation, it was determined that no self-respecting game maker can call itself complete without some basic dynamic shadow functionality.

To this end, primarily because issue 555 will take a considerable amount of time to get right, we are posting it as a forum thread so we can determine to what degree we would fix this bug.

I have asked Preben if he would like to take on the task of adding shadows to flashlight and dynamic lights, and we are looking at the best part of a month to create the initial implementation (2 weeks) and then the testing and iteration through the beta and PP builds to make sure it works for the many game making projects out there. The cost to do this professionally would be in the thousands but Preben has agreed to do this for £500 if it came from a donation pot.

So as to keep the 'bug fixing' pot available for other issues, for the next month or so, we will designate the 'Miscellaneous' pot as the fund for fixing issue 555. If you feel this is something you would like to contribute to and accelerate the start date for commencing this task, you can donate using this link: https://www.thegamecreators.com/donate/project/1721

Given the performance killing consequences of shadows cast from point lights (i.e. rendering your local scene 6 times, creating a cubemap and applying it as an extra set of texture references to every surface that needs to render the shadow, and doing this for EVERY dynamic light you care to drop down), we have come up with a plan to provide functionality for issue 555 without impacting performance too much and putting the control of where shadows appear with the creator of the game.

The shadow system will be upgraded to include:

1. Shadows will be cast from the built-in flashlight system, with the flashlight source offset from the camera position so you can see the shadows being cast (i.e. if the light source and camera where the same position, you would never see a direct shadow).

2. Shadows will be cast from Dynamic Spot Lights, and limited to the nearest X lights. The X can be defined in the SETUP.INI and capped at an internal maximum so as to preserve performance on highend systems.

3. Dynamic Point Lights will not cast shadows.

4. These extra shadows can be switched off (as they WILL affect rendering performance).

Before any contributions are donated, I think it makes sense to flesh out this subject and agree on the work to be done. It could be you are not interested unless point lights are included, or you believe that time should be spent elsewhere and dynamic sun shadows are sufficient. Feel free to make comments and we will report on the status of the donation pot in this thread. This is the first time we have used the donation pot system for a specific well-described task, and it will be interesting to see how it plays out.

You mean I gotta go first? Well then, I'll just give it a big thumbs up,
without much in depth feedback (at the moment), seeing as I'm a
noob and there's others with more experience regarding the light.
Cool. Let's go!

One question. Point lights cast lights 360 around the entire area?

Thank you. This is certainly a step in the right direction, imo. As I've stated before, dynamic lights not casting shadows is a show-stopper for me. However, I would still like to see dynamic point lights casting shadows. Most game engines allow for this and it can be very useful. Instead of restricting it so that they don't cast shadows, why not have a check-box or selection field that allows the end-user to determine if any light placed casts shadows or not? This way, it is up to the end-user if they want to include the feature (and, thus, cause any potential slow-downs that might occur)? Many game engines I've tinkered with allow for this. Ultimately, it provides more control for the end-user, allowing them to turn on/off whichever features they need/want for their games/projects.

Yes please Lee, this really would be a fantastic edition to GameGuru. Go for it.

Excited to see this added.

Sounds good!

what would be a general amount to donate, in US dollars, please.

Amazing if this all works out

Im in ..
Started the ball rolling by donating £10

I did not understand it. Should we collect 500 dollar or do you already have them and spend them now for this?

Cant really use funds from other pots ( if that's what you mean ) .. Users donated that to be spent on specific tasks …
Gonna have to start from scratch with this one.

If we get dynamic shadows could we please have a toggle in the game menu options to turn dynamic on and off, one of the first things hardcore gamers yend to do with new games is to turn off dynamic shadows because they're a huge resource draw.

I agree that it would be a good idea to have a means for the end-user (the game player) to be able to toggle dynamic shadows on/off. However, I completely disagree that "hardcore gamers" tend to turn off dynamic shadows on new games for any reason. In fact, most "hardcore gamers" try to build systems where they can run games on high or extreme mode. And it really doesn't take all that much of a PC to do it. However, there are those with slower PCs that won't be able to run the game well regardless and being able to turn them off, in the game menu, is a good idea.

If this actually comes to Game Guru (which would be absolutely amazing) it would be wise to add it as being a toggle able via the setup.ini (at the least) as some players might want control over performance.

I'm all for this feature by the way... i have way too many project concepts that would benefit from this.

I am really glad we came to that agreement.



I agree with that, otherwise we would have to use multiple spotlights for some light sources to look realistic, easily eating up the entire budget for a single lightsource.

Is this entirely and solely funded by the community? if it doesn't reach the intended donation goal, would TGC be topping off the remainder to complete $500? Also if this is not the case, would this feature effectively, not be worked on if not funded in whole by the community by the intended start date of work?

That`s an interesting question. I would have read it as Preben is doing it for this super discounted price which I assumed would be paid by TGC upfront, and the community just refills the pot "misc" because it`s symbolically emptied ?
I have some issues with English as it is not my first (and not even 2nd or 3rd) language, but I can`t believe a fix for a commercial product that is still marketed and sold would rely on "donations" to begin with?

A clarification would be highly appreciated.

@Ertlov: You are right. Does it seem strange to me that customers who bought GG still have to support the development? (especially if it is a function that should already be there). It is unthinkable if such "functions" are being asked for money from the community. The TGC has been here for 20 years and it is sad that they treat their customers this way.

As said, that can be a misunderstanding. I find it really hard to believe, so let`s not jump to conclusions and wait for an official statment.

With TGC aside Personally I just look at it as a little Payback for all the free work Preben has done for the community ..
I will just keep adding more when I can and am happy to do it .. Don't care who pays but I do care that Preben gets something back for all his efforts and hard work.


I admit i pushed hard for a donation section … This was so Lee could sub out the work he just couldn't do himself as it was just to overwhelming ( something like this really ) … But its a free choice, nothing forced on anyone and to be honest TGC were dead against it anyway for this reason... I don't see it as a fix or bug .. its just not there. Its a case of get it sooner rather than later .

With all due respect, that contradicts directly Lees statement in the first post.



Not complete = incomplete = unfinished.

Of course I am here biased as I pushed for that, but I can go out and ask 20 of my colleagues in game developement all around the globe from Indie to Ubisoft or IO and will get the same arguments I brought myself.

We wouldn`t have the discussion if it was something even more obvious like "dynamic objects cant have textures, only flat colours" or if we had a 100% functional lightmapper not running into a ridiculously stringent memory cap, but it is what it is.

As Lee said, the discussion is over and settled.

The actual question was raised by Teabone:



and, frankly, can`t be the answer.

As for:


I get your intentions were good, and it is always good to reward community members contributing to development, but we are not talking about a foundation or an open source project ran by enthusiasts. We are talking about a for-profit company selling a product, still selling it, releasing DLCs commercially, all that on the largest global software distribution platform. Even using the term "donations" would be legal jeopardy on many countries (obviously not UK). Business conduct would be to hire either employees or freelancers at their respective rates. In this case, with the sales numbers from GG and the DLCs PLUS the pledges that were cashed in beforehand, I find it hard to believe that no budget can be allocated for that, especially if there are people like Preben working for such discounted price tags. Also, don't forget that revenue is still generated from the product (and the DLCs), AND it is not the only revenue generating product in the company.

Thank you for saying this, ertlov. I was thinking it, but debating whether to post something along these lines. The Game Creators is a company. They've been offering products for sale for a long time, going all the way back to DarkBASIC, etc. They've sold various game creation tools with various flavors (basic and pro versions, for example) and DLCs. GameGuru is not some OpenSource project available for free to all and relying on donations to keep it improving. It's one of several products for sale by a company. And if that company cannot allocate $500 to get some coding done, then there is a major issue with the company. In fact, I was surprised at all the community has been doing (for free?) to help improve this product that the company, The Game Creators, will keep selling. Sure, I get that the current users of GG want a better product and want to be able to make games with it. But when people volunteer to improve it, aren't you really just making a better PRODUCT for TGC to keep selling? Yes, user contributions benefit us all, but aren't you really just benefiting TGC bottom line? Users doing the coding allows TGC to keep developing other things, like the new AppGameKit Studio (or whichever one it is). I bet AGK Studio has dynamic lights casting shadows.

Lee was actually quoting a post on github with ...
" it was determined that no self-respecting game maker can call itself complete without some basic dynamic shadow functionality."

I simply don't mind donating as I said .. so we get it sooner rather than later … It wasn't meant as an answer, just stating the obvious. But hey it was just my thoughts no biggie ..

"I bet AGK Studio has dynamic lights casting shadows. "

Oh, probably. I would hope so. Which brings me to a point (or two).
Isn't there a plug-in or existing code platform? -//- every engine that's worth
anything has this, so why isn't it more like a part that x company can obtain
for x$ that is inserted into the code and not just something developed from
scratch all over again?

I'm guessing it's not that simple, but it also seems like it should basically be
there somewhere in cyber land that can be acquired readily in 2019- even
if some tweaking/ formatting is necessary?

As for the donations rhetoric. That one's also a new one to me, as I don't notice
it from any other commercial, self contained enterprise on Steam or anywhere
else-- only open source...? Oh well. I've already "donated" quite a bit to the store
on a regular basis. That's why I suggest DLC's like Character Creator, or even
a GG Studio that can be a separate higher level product that supports itself-- which
would be the one with dynamic lighting shadows and 64 bit.
Even a Menu Manager I would also support via DLC.

The store is third party, it is not owned or run by tgc and nothing to do with gameguru development, also the models are made by community members, so your "donation" has nothing to do and doesn't go anywhere near gameguru :p

According to Lee, in an email I had with him about possibly developing a DLC, at least one of the model packs is owned by TGC. So, any sales of that pack go right into TGC profits (after Steam takes their cut, of course). And since TGC is the parent company/owner/developer of GG, then perhaps some of these models have at least a little something to do with GG (i.e. they bring in funds that TLC can allocate toward GG if they wanted to). Also, in the same emails, it was explained to me that the sales of DLCs would be split - a certain percentage to the designer of the DLC and the rest to TGC. To be fair, the email did not exactly specify that TLC would get the remaining percentage, but it also did not state otherwise and this was in an official email from TGC and a third party was not mentioned.

"The store is third party, it is not owned or run by tgc and nothing to do with gameguru development, also the models are made by community members, so your "donation" has nothing to do and doesn't go anywhere near gameguru :p "

Oh, shucks. TGCStore.net has nothing to do with TGC or GG?! Oh man, that's weird!
It's a bummer and depressing a bit. Even GG editor links directly to it.
But don't get me wrong. I love TGCStore.net If I had all the money in the world,
I would be on that store all day and all night. Because the best artists around
participate in that store -- and the best for GG especially there.
So all that makes the whole ordeal a real mystery. Hmmm...?

Yeah now DLC's. I always thought DLC's where basically tied in to the game they cover.
Again I reference other products on Steam for possible reference. IDK?
I'm beat, guess I'm defeated before I even arrived.

The store used to be owned by TGC but Steam were taking so much of artists profits they sold it on to a third part to run ( Jason in fact ) and obviously GG artists still submit their content ( only the ownership changed ) its still community driven.

DLC's on the other hand have nothing to do with the store, not even available there. They are created by a third party but specifically for GG.

Interisting point of view about lighs & shadows, though.
How do modern game engines handle many shadow casting lights?

I have raised this in my original fix request on GitHub.

To be more precise, the Shadow Budget Calculation

This makes no sense to me. I get that some users have literal potatoes plugged into their monitors but why is it that the users with decent hardware always get the shaft? Why not just put an option on the properties tab of the Point Light entity that says,
Cast Shadows : On/Off

As others have said, I too already am thinking of ways that I'm going to have to try and fake a point light casting shadows. Probably have 12 spot lights forming a circle or something stupid. Just having 1 point light able to cast shadows, with a little creativity, could go a long way.
Just stop catering to the people with low end hardware. I mean good god, Doom 3 came out in 2004! And it could have 12 dynamic lights in 1 room all casting shadows. 2004.

Ye but even back then they had over a $14 million budget to play with.
We just need 500 bucks
J/K

Yeah, but to be fair they used more often 1-3 cleverly placed ones, in very small rooms. And the engine was written by the gods of 3D engine programming.

But I think we all agree here that limiting shadows to spotlights is pointless.
Pun intended.



This and the limit of at once in settings.ini and we are good.

This improves the realism of the game and the player has the final choice.
I'm afraid this will take some time.

While I agree the utopia would be to have any type of light able to cast shadows I don’t think GG will be able to cope with it using its forward rendering path. To change this would be a huge job and take a long time.

For now I’d be (extremely) happy if spotlights and the flashlight cast a shadow. To save cycles it might help to have a switch that turned off the sun shadows whilst spotlight/flashlight are turned on. There are often many scenarios where sun shadows aren’t needed at same time as other types.

Dynamic spotlights with shadows can be used very effectively.

There are other factors at play with GG that even a beast of a machine won’t help with and irrespective of who should pay or do what I’d caution about asking too much at this stage.

I honestly think that the plan outlined by Lee is the pragmatic way forward for now and we all know Preben is a graphics coding expert and I’m hugely thankful he’s even considering doing this difficult task. So don’t think we should be making it so very much harder.

I can see the arguments about what other game engine teams have done and can do and am one of the gold backers of reloaded and have been here years so share the angst of what was promised and where it’s ended up. I agree too shadows should be a core facet and built into GG already.

But we are where we are, so if Preben is wiling to take on the task as outlined I think that would be a great step forward for us and will donate.

Cheers

Maybe this will be a stupid comment because i lack the needed knowledge on how all this works but i'll write it anyway.

What is running through my simple mind is the question if it is possible that entities somehow can block the light from penetrating through the entity and hence creates a non illuminated patch.
Would something like this be doable?

@Ertlov Just for clarity, I personally do not agree that the lack of a feature can ever be called a bug. The wording of my statement was carefully selected ("After some conversation, it was determined that no self-respecting game maker can call itself complete without some basic dynamic shadow functionality."). It was determined by a section of the community. The needs of the many outweigh the needs of the few. It's now my job to make it happen in a way that keeps the good ship GameGuru sailing.

@Tomik18 @Argent Arts : Thanks for your feedback. Are you recommending we scrap the donations system and keep all costs in-house? If not, what value do you see in continuing the donations system? Happy to hear your thoughts!

@Kitakazi : Would you consider a "dynamic shadow system without point lights" a 'half-baked' solution? We can keep the development of this in a private dev branch until it's fully complete.

@Earthling45 : You have the general idea of how shadows work. Specifically, we need to render the entity from the perspective of the light, and then use the depth information from that rendered entity to determine if a surface point is in front of or behind that entity. If the surface point you are interested in is behind the entity, we can shadow it. This is pretty simple for directional lighting like the dynamic sun shadows, but when you have a point light you have six different perspectives from one light, and you need to render every entity visible from that perspective to the side of a cube map, and then read that cube map in any shader that needs a shadow which is most entities in the scene. A point light without occlusion can easily rerender every entity in its local vicinity 60 times a second, and that's one light Given such workload, there are different optimization methods for doing this 'shadow pass' quickly, such as a deferred rendering approach, but this would be a substantial rewrite of the current forward renderer. Most modern games use some form of deferred rendering to solve these 'batch operations', to deliver point light shadows we will need find a nifty way of doing this efficiently so we can keep good performance. It won't be a quick task, that's for sure!

@All : Thanks for the feedback on Issue 555, lots of good comments here and really hammers down what it is we want from this work. Just for clarity, there is no TGC funding for this work as we are putting that into non-issue-555 bug fixes, tweaks, and other activities for the moment. It was simply an informal agreement between Preben and myself that we could kick start this task early if the community wanted it to happen via the donations system. If there is no interest, it will still happen of course, just in a different order and at a later date.

That's pretty much what I'd be looking forward to. Even if we have just one dynamic that can be swapped to either the sun or flashlight. I, of course, have no idea of the scope of work for something like this. But if its happening that's great. I was just curious if the possibility of it not happening was there, if donations were not met.

That was also my take on it ..


This is something I really want to see ( a big step forward ) so if the donations don't make it but a reasonable effort is made I would pay the balance to get things going ..

Absolutely agree.

Thanks for singling me out (and Tomik18) even though erlov was the first to bring it up (and I was responding to him). But, yeah. If TGC is a company, then you create product for sale and, based on your sales, you create new products or update old products. Companies make their money off the sales of products or services, etc. Donations are for not-for-profits, such as charities and, in the case of software, opensource, etc. So, if TGC were to be a not-for-profit, creating opensource software, then get all the donations you want. Else, hire your programmers and pay them a fair wage to do the work.



You are correct. It's technically not a bug. I agree. However, not all showstoppers are bugs. Some are lack of features. Dynamic lights casting shadows is a showstopper for some (me, included), but not for others. So, technically speaking, this feature is not even essential. However, it is a very, very common features in most engines these days ... even those that are not new. Having this feature would benefit GG and many in the GG community.

Concerning the other comments on dynamic lights casting shadows, develop of them, etc. ...

I know another inexpensive engine that has a lone developer. He isn't asking for donations and isn't requesting the community to help with development of his engine. Regardless, this particular engine does indeed have dynamic lights casting shadows (and not just spot lights). In fact, he's gone on to push this idea even further and found a way to add good dynamic shadows with relatively low overhead. So, I know it can be done (regardless of the size of the team of developers and the budget).

Some may say, "Well, then. Go use that other engine." Sure. Perhaps I will. Perhaps others will. But that's not the point. There is something interesting about GG and, frankly, I'd like to see it grow and thrive. However, this attitude toward dynamic lighting, how difficult the developer makes it seem to be, etc., is really a downer, to be frank. To me, it's relatively simple: having a lightmapper that works properly AND having dynamic lights (ALL dynamic lights) being able to cast shadows is a must for a modern game engine. GG currently has a lot going for it, but it needs a bit more to be a better alternative to some of the other stuff out there.

I may come across as negative, but I do like GG and like what it's potential could be. And perhaps that's the reason I come across as negative - I see this potential, but I don't know if GG will ever come close to reaching what it could be.

I wouldn't say that dynamic shadows are "not here" as the sun is casting a dynamic shadow. Entities walk and the shadow casts dynamically.

Would be nice to have dynamic control over this. I know the skybox settings allows for some directional controls for this in some way.



Be cool to see it completely dynamic like this:




Even with a TAB slider would be great and also handled by LUA. I thought this was actually something that would have been coming around a few years ago. Not sure where I got that notion from. I'm assuming this wasn't implemented entirely due to performance risks?

The more I read about lights and shadows, the more I realize its complexity.
I suspect that we will have to be very cautious in its use.
The control of the light and shadow system must be completely dynamic, both from the properties panel and / or setting files, and from the LUA commands.



Source

The fact if it is a bug or feature is not the issue here, the mayor issue here is the implementation itself, the resources handle/release when unnecessary/unused, could be the icing on the cake.

This is an interesting discussion as it sort of mirrors the sound issues I cover in my thread, asking for all light sources to cast shadows would be analogous to asking for all sound sources to cause echoes.

In game engines you can't mimic reality by brute force simulation, instead you have to find a way of faking reality in a way that is realistic enough to fool the player, it's a bit like film making where the viewer is fooled into thinking they are hearing the footsteps of the actor on screen but in reality they are hearing the foley artists rubbing a block of wood on some sandpaper or something.

All you really need is enough 'fake' shadows to fool the player into thinking that everything is casting them!

Great idea by Teabone.
A TAB slider for the sun settings would be cool. And a step forward

This would imply lightmap the scene in real time and use it rather than constants shadows calculation, and so on.
I can not think of how to do it when the shadows are dynamic.

A lot can be done with a very few dynamic point lights, lightmapping, and using things like light probes, especially since GG has PBR. So, yes, properly lighting/shadowing can be intensive. But a lot of that is on the game developer. Just because an engine can display 100 dynamic point lights, all casting shadows, does not mean that you, as the game creator, should have 100 dynamic point lights all casting shadows. In my opinion, the engine shouldn't be the limitation (as much as possible). Let the game developer decide (or learn) what limitations they should impose in their games.

That`s why I always worded it as "user-placed dynamic lights dont cast shadows". And I won`t start the discussion "bug or feature again", promised, as Argent has said all that needs to be said:



I am more interested in the solution, for obvious reasons - and some kind of super-rough roadmap / ETA.

Teabones question regarding funding and timeline was answered by Lee here


As I am not familiar with the British business laws, HMRC guidelines regarding the usage of the word donation and donation-based business actions on for-profit products sold by for-profit companies, I will not add any opinion myself here. While I can understand some users questioning morality and legality here, I am sure a company with 20 years of business experience knows the finer detail of their national economy environment.

The only thing that really bothers me is that none of the wordings gives a real sense of timeline - are we talking about weeks, months, quarters?
If we had some clear statement like
* With donations, you have it in a month
* Without donations, End of the Year
it would be a much clearer goal, and I would put cash in far more easily.

In General, I apologize for bringing that up so late - at least in GitHub. In the Forums and the Beta Discussion back then with FPSC-R I have raised it on a permanent base.
So, yes, I should have raised and escalated the issue in GitHub earlier, but I was waiting for the outcome of 6 months of pure bugfixing that were announced and communicated for the first half of 2019. Partially under the assumption it might be included anyway (my wrong) and partially because I was pretty confident that after such an extensive work committment by TGC, major "clear" bugs would have been squashed and the work on necessities could start.

Obviously, I was wrong here. So a clarification regarding the timeline would be highly appreciated.

Thanks for the replies. No timeline set for the next update, or what will be in it, only that priority will be placed on items in the issues tracker that tackle 'bugs' before 'enhancements'. I am anticipating August for beta and PP testing, so if that goes quickly then September for the next public release.

@Argent Arts: Can you send me a link to the game maker created by the lone developer? These days it's pretty brave creating a game creation tool with the standards and competition we have today, and it will be useful to make some comparisons as it sounds like we're equally matched when it comes to resources. On your points about hiring and running a business properly, if you managed a product that could just about sustain the fair wage of one programmer, and that product needed updating, would you hire a second programmer to get the work done quicker (and push the product into a monthly loss), or stick with one programmer and take longer to do it? Such are the decisions when development software!

@All: I was not aware the donations system was breaking legal or moral laws, it was just a simple way of administering voluntary contributions from the community to pay freelancers who wish to volunteer their services for things the community wanted to see sooner. Indeed, it would be less hassle for TGC if we scrapped the system as it does take time to manage, and given the negative feelings it is generating, it might be best to end the experiment once the last of the pots has been spent.

As far as i'm aware, it does not break any moral or legal laws.
It has been discussed with the community and implemented accordingly.
any development on GG is not dependant on donations as far as i'm aware and i can imagine that the cost of the list of bug fixes from the june update easily be in the thousands of euros.

Of course there is a benefit for TGC if freelancers elevate the value of GG through implementing new features but i can see no wrong in this as it is entirely voluntarily and we all benefit from it.

Done via PM.



Way to take my comments out of context. You asked for my feedback on the donation system and I gave you my thoughts. They're pretty simple - if you are a for-profit, then you don't ask for donations from your customers. You sell your product or service. If you are opensource or not-for-profit, then you can ask for donations. These are my opinions only. It's not about what is or is not proper, but my opinion (which you had asked for). Even so, concerning hiring, I truly believe a workman is worth his hire, as they say. Preben may be willing to do the work for $500 and that's great. But he should be paid a heck of a lot more. He should be paid a fair wage for the work, especially since he will be improving a product which you will be selling and continuing to (potentially) earn a profit from. To take donations to improve a product that you will profit from is just ... wow ... (again, my opinion).