I disagree about the media thing here. The media is provided by TGC to show off GG to new users and give them something to use. It would be far better if that media was optimised from the get go and also give less chance of bad reviews. Not everyone is that committed to making games that they feel the need to work on every aspect of it (graphics, scripting, sound etc.) That is what the store and other online offerings are for. I think sometimes the committed people around here (including myself on occasion), expect a little too much from the casual users. Sure, you shouldn't try to knock out a steam game within a month of getting GG, but it will always happen, some people will do it regardless.

I also disagree about reviewers mocking games with stock assets. Sure, they do. But the stock assets aren't the issue here, the rubbish games are. If the games were good, playable and engaging, most people wouldn't give a fig for the stock media thing. But as they generally aren't, the stock media is just another thing to point and laugh at.

Saying media shouldn't be updated when it has known performance issues is like saying leave the bit of code that's slowing things down as it's only stock code. I can understand people not wanting to use stock assets, but also respect that many (probably the majority) do. At least for some items. I'm sure most have a mixture of default, store and custom. Default foliage is one that many people use regularly. It should be updated to work better. It can only improve peoples perceptions of GG if the media that comes with it runs well and doesn't slow to a crawl by spraying a few trees about. Also, I haven't seen too much decent foliage around either. I have some purchased stuff, but in honesty mostly (not all of course), it's not the best and I rarely even look at it.

Here, getting back on the subject, is what I think GG needs this year.

Bug fixes.
I think this is a big thing. I'm always finding some issue at some point that slows or stops progress. All known bugs should be squashed.

Improve what we have.
Instead of barrelling onto the next feature, lets get the ones we have working to a more acceptable level.

Lighting for instance, one of the draws for moving to DX11 in the first place. It's improved from where is was, but it's still far, far from great.

PBR, again looks okay, but still nothing close what we see in other games out there. I wasn't a fan of this being introduced really, I would have been happy with DNS as long as the lighting improved. But we have it now and as such it needs to be better, or what is even the point of it?

Water. How many conversations have users had about this? Having multiple levels and water boxes etc. I remember Lee once talking about flowing rivers and streams. He even took pictures of a river to get some ideas at the time! What do we have after all these years? One water plane.

Terrain. I almost hate to mention it, as the last terrain update for me made it worse. I can safely say I haven't really used the terrain painting tool since. It looks awful. Oh and I hear the tweak to get the terrain scaling to height and will have a look. However, why is it that it isn't default? Why do I have to go change setting to get it to work as it did before? Seems wacky to me, certainly not user friendly as GG is pushed as. It's probably a performance thing. Talking of which, it's about time the terrain was de-hogged

Standalone. Everyone knows there are issues. A game making utilities focus should be on making stable games. Get it up to snuff. I hate how it works presently. Whatever github issues are listed should be worked on. Now, I have defended this in the past as GG is work in progress and it makes sense to get the standalone sorted when all is pretty much set in stone. However, that is never going to happen and as such the standalone needs some TLC.
As stated above, menus, GG standalone menus remind me of a Spectrum menu from the 80's. Also, why on earth do we have to provide an image for every resolution? We should provide the highest version, then GG should scale the rest to suit. It makes it more cumbersome than it needs to be and adds bloat to an already pretty big file.

Time is a ticking and progress marches on. Ray tracing is now a thing in games and of course it is DX12, so we are already falling behind once again. Fair enough, it's not a big thing yet and performance is not what gamer's want apparently. However, it is brand new and as such fits the usual product cycle. The next cards will be streamlined better and performance will start shooting up. In just a few years we will probably be starting to wonder how we ever played games that weren't ray traced

Thanks for the VAST feedback Now consider that in just over 24 hours since my previous post, we've just listed a few years worth of work for little old me, you can see why I am in need of freelancers Sounds like the 'hide half-baked features' idea did not go down too well, so don't worry, the community have spoken and we will keep these ugly little ducklings around for you to play with some more I do repeat though that what I would like to focus on for a while is 'pure bugs' and anything you can reproduce that demonstrates instability or functionality that is contrary to the available documentation would be much appreciated if they all existed on the GitHub issues tracker. Once those are out of the way, we can classify the ugliest of the so-termed half-baked features and decide what to do with them on a case by case basis.

What IS going to happen in 2019 is the branching of GameGuru into two code bases. The first and the one you are familiar with will be the one that contains all the bug fixes, tweaks and improvements that are reported in GitHub issues tracker, and the build you currently get on Steam. The second will be used for ANY new features going into the engine, thus removing the potential for any more half-baked features to make it into the master product. Only when those new features are completely 100% 'good enough' (which I accept is a very subjective condition), then we would 'consider' making it part of the main Steam product. I think a worthy goal in 2019 is to reduce the number of confirmed bugs and smooth/polish those aspects which are almost there but not quite. If we have users out there who find some features 'seriously unacceptable', it might be quicker to learn C++ and help fix them as I can imagine the inevitable wait for a 'repair' would be increasingly excruciating given the 24-hour short-list above, and as a bonus you would have the undying appreciation of an entire community

My guess is that if we stop adding new features into the main product now, perhaps in a few years we'll have had time to fully bake all existing features and have a pretty awesome product on our hands. It will be interesting to see how we walk the line between completing a feature, and infinity improving it

Sounds like a good plan to me



Dave

Wow. Thank you. Not expected that since this thread: https://forum.game-guru.com/thread/220208
But it is the right way

"Standalone" needs to be looked at really bad. There are many bugs. And even more frustrating is when I purchase the official model packs and then the models do not work correctly in standalone. Some don't show up, some textures are completely messed up. The wall lights from the cold war pack are really funky in standalone.

The fix for missing models or broken textures is to drag the file into the standalone folder after the game is built but it's starting to get out of control. I have all these files in a folder that I have to drag into standalone everytime I test my game and my game isn't even half way finished. And the folder is getting really big. Some files are custom and they won't be encrypted because of this...

Then as others have said performance. I personally don't care about load times and I don't mind waiting a minute or two for a level to load. But most players don't like waiting 2 minutes for a level that takes them 4 minutes to beat. And then the chances of it crashing on a load screen are incredibly high.

They should try some online games like Battlefront 1 and II ..
It takes nearly 20 minutes before you actually get to play in most cases and about 3 minutes to exit back to Desktop when your done.

" we can classify the ugliest of the so-termed half-baked features"
Light & Shadow

I'm simply relaying information that I receive from play testers. It is a complaint that almost all have brought up. While I'm sure some of the load times are from my levels not being fully optimized, it is hard to justify load times over 2 minutes for a level that takes a player 4-5 minutes to complete.
And it's not even the long load times I'm worried about but another issue that seems to be pop up because of load times. When I have watched testers play (in real life and/or streaming to me privately) here is what I have seen on multiple occasions.

Tester launches the game.
Tester starts the game.
The load time reaches about 15-20 seconds, the loading bar has yet to move.
The tester clicks the screen or possibly alt-tabs to make sure the program is running.
Game-guru crashes / or "this program is not responding" error appears.
Tester closes game.
Repeat.

Last time I tested I had the load screen image black with white text that said "Please be patient, loading times could take a couple minutes." Yet what I described above still happened. And I dunno maybe it really isn't that big of a deal, but if players get frustrated before the game even begins, then the whole experience is already suffering.

The loading time does also depend on systems of course ... Mine takes around 10 seconds to load from the main menu but they are quite small levels. Im so used to long loading AAA games I guess a minute or even 2 doesn't seem that long these days .

I was just about to say the same syncro, none of my systems take more thn thirty seconds to load levels, i even tested a while back when lee improved loading times and a level with literally hundreds of trees and humdreds of other entities took anly 25 seconds to load.

Importer (character in to gg) ?? not 100% ( user friendly )
character creator. ?? whats gone happen.
Copy and paste. ( group of entities ) ?? Please.

Sorry had to say this.


Pcs

Yeah and by the time it will be just as out of date as FPS Creator was then you can announce GG:Reloaded….
Stop adding new features for years and focusing on bugs and polish is something I was hope never see it come up. I was hoping the very opposite. I understand there need to be a freeze time to time and focus on bugs and polish and it is obvious TGC not doing great financially but the development of GG is just way too slow for me and after years of waiting and this statement just closed the gate for me. I give up on GG.

I guess it time to consider GG a giant asset pack ONLY with a cool PREVIEW engine called GameGuru in which case I have only 1 very last thing to request for 2019 and beyond.
Please Include GG assets in dae, fbx and other formats even as a separated download/DLC pack so we can easily take them over to an other engine. I would even buy it. Seriously.

I would also recommend to reconsider one more time to make GameGuru a wrapper/plugin for an other engine. Godot and Xenko would be pretty good option. Both completely free and open-source under MIT license, also cross platform and capable. If you don't have the resources to develop your own engine why even try it?
There are tons of cool free and open-source engines , grab one, add the assets, write the scripts, create the prefabs that we can just drag 'n drop in to the scene and call the package GameGuru. Done.
Again. Xenko and Godot are the two best options in my opinion . Unity and Unreal is the other two but licensing may don't fit everyone including TGC that's why I recommend either Godot or Xenko in the first place. Godot also received a new PBR renderer recently and it even got a nice plugin system and even a visual script editor. Making GameGuru a Godot plugin that we can use to make games in Godot with drag 'n drop assets in to the scene and then extend it with Visual Script or one of the supported scripting languages sounds really good to me.

If not making GG a wrapper or plugin, not a problem, but I don't personally see GG is going anywhere and you just confirmed it won't, you put the breaks on and focus on bugs. Which is fine, I understand bugs need to be fixed, features need to be polished but the time scale you proposing doesn't fit me. You told years ago it will take few years for GG to become a solid product and now years later you mentioning another few years to go. Fine, but I'll go and look from the other side of the fence. I can't wait any longer. I've been waiting since the announcement of FPSC:Reloaded and can't even say we got a decent FPS engine. There is nothing decent about GG except the amount of assets included. GameGuru is a complete waste of time

When I was recommending years ago, at the very beginning to make GG a wrapper, you told NO because you want full access and full control over the source and now you have full control, but you don't have the resource like time and money to take advantage of that. So here I suggesting again. Go and grab Godot and make GG a plugin for Godot or fork Godot and use it as a base for GameGuru. If you don't like Godot, there is Xenko… But again, if making GG to be a plugin or wrapper only or build GG on top of open-source tech just makes no sense, please at least consider making the assets available in dae and fbx format so we can use them in other engines.

However you decide, I wish you good luck.

yeah, GG as a unity or UE plugin/wrapper would literally be a bigger success due to ue/unitys bigger communities and the fact that it would actually work better

GG has always been out of date as has been FPSC even when it was first released. I don't see it being any other way and this is not a state of the art engine and never intended to be.
However, if FPSC would not have the memory limitations it would probably still be widely in use and I think the same is true for GG and its few lacking features. (Memory, stability, performance). These three aspects are where it needs to be updated severly.



-Wolf

After reading everything here, I tried to distil the most common comments into three categories.

• = Priority 1: Actual bugs that need fixes
• = Priority 2: Features that aren't finished
• = Priority 3: New features yet to be implemented

And, as I see it, what we're looking at here is:

P1s
• Fix the position/scale/rotation widget
• Multi-textured models using same _normal, _gloss, _metalness map throughout
• Build standalone often fails to copy over files. I've noticed it particularly with global sounds (despite them being named specifically in LUA) but it also does it with custom sprites too.

P2s
• Fix lightmapper. Either go full dynamic, shadow-casting lights only, or do the mixture of static and dynamic we used to have, but both light types need to be as bright as each other. All entities should be rendered at equal brightness regardless of whether they are dynamic or static. Also wall thickness should have no bearing on whether something is lightmapped, nor should backfaces.
• Real world reflections/reflection probes on PBR assets.
• Do away with the terrain texture hierarchy so we can blend any combination of the 16 available textures.

P3s (would all technically be new features)
• Paint multiple grass types.
• Dynamic or at least editable sun positioning.
• A search function in the entity bank. Even the rudimentary one in FPSC was a god send. An additional line in the fpe for metadata would really help too.
• Water. Better looking, better behaving, more editable, more 'ploppable', swimmable water.

P0s - what I like to call always-on, or ongoing (these ones never get solved, they just get improved upon)
• Better performance from the engine (more efficient rendering, loading and uploading of assets on the fly, memory management etc. )
• Better stability for both the engine and our final standalones.

(I also have a long list of other features that I'd like to see added, as I'm sure many of us do. But for Lee's sake, I won't post them here until he asks for what new features we'd like to see)

I think artists like myself should also do more to produce content that is optimised as much as possible. The Game Creators Store has tons and tons of assets with enormous 4K textures and no LODs, and then we all act surprised when our levels don't run smoothly. Every object in Game Guru should have LOD models, and mipmapped textures (that extends to DLC packs too). Ideally Lee and the devs from their side would make Game Guru manage these assets more effectively too, and also make it easier to specify LODs at the import stage, perhaps even as separate files (e.g. merge model_LOD0.fbx and model_LOD1.fbx into the same .dbo).

Someone made a point about stock media being overused but honestly no one cares when it's used well. No one cared that my game Extraction Point was 90% stock media, they cared that it was playable and enjoyable. I think we need to look internally at our own creations before criticising others.

And lastly, the single most important point I feel I should make is that many of us got into Game Guru because it was billed as a 'easy game maker' for those who don't like to code - why else do you think it became so popular with artists? Yet so much of Game Guru's best functionality is buried in LUA script. All the amazing work Amen and GraPhiX did on particles is ultimately rendered useless to 98% of users because there's no WYSIWYG GUI to design these effects in the editor. Just like there's no GUI to design menus, no GUI to chain AI behaviours together. Ease-of-use should be the single most important guiding principle behind every piece of functionality in Game Guru, but at the moment it feels like this engine has become a playground for a small group of dedicated LUA enthusiasts. You will always get users who will exploit scripting to create their own unique things, but that shouldn't be a prerequisite to create a game beyond the complexity of The Big Escape. And, right now, it feels like it is.

AE

I have to say for myself, that a larger texture then needed is put into my media, giving the buyer a nice texture to scale down as they need to accommodate the model's usage.

Better to he to scale it down, then try and scale them up.

I've yet to sell anything on the store but when I do, I'll be including the source .pngs at full res in a separate folder, and the game-ready mipmapped .dds files at, for example, 1024 x 1024. Then it's up to the end user to choose if they want to use the higher res ones. I've been thinking about doing that for LODs too, including each LOD as its own mesh in a separate 'model' folder, for users who want to truly optimise their experience.

AE

When playing games made in DX9 Game Guru that were on steam i noticed they would crash if you attempt to alt tab out during a load process. I believe this might have been fixed since then? There arnt any dx11 GG made games on steam i can really test with that im aware of. Certainly not ones i want to pay for (lot of crash-grab uploads there).

Load times problematic -- YES.

Standalone problematic * -- YES. YES!
*missing models or critically corrupted components (ie Story Zone/ Image Zone/ Win Zones not working.)

View Steam commentary- good results seem to be the exception when you are making those
projects that are beyond the shoot- a- group- of- soldiers- type. But I wish GG well.
The optional engines are their own camp.

We have a rather nice issues tracker if you want to add your report: https://github.com/TheGameCreators/GameGuruRepo/issues

Curious - I was under the impression LOD meshes have to be included in one model.....

Reliquia....

LOD levels need to be individual meshes within one object to work with GameGuru as it is.

I suppose you could use separate models for LOD, but you would need to script a way to show and hide the different levels at different distances, but i have a feeling just the act of adding those scripts to show/hide the models might be more resource hungry than just using one model with LOD levels and the automatic LOD system.

Hopefully when, if i get my github stuff sorted out again i can start posting some work ive done up there. I converted all of the animated trees in foliage to still trees. So that users would have the option of animated or still. Not just by turning animations off, but i've gone in to the original meshes and completely stripped the animation frames away from them and made them separate new entities. Game runs a lot faster with these trees. Also good for having near trees that are animated and further ones the player cant really get to, still trees.

In my opinion, the efforts for the new year should all be made for the 3rd person.

Having the possibility to fully use the third person, would mean a lot for the existence of the engine itself. Especially for the chance to create more original and different games.

I hope this year is the right one.
Otherwise, rename this engine to "FPS Creator II"

I think the global player LUA script should be split up into two. So that the first person is completely separate from the 3rd person. And I guess the script swapping would happen in the editor when you place a character on the start marker.

Doing this will make it MUCH easier for us to fix up and add features to 3rd person and FPSC. Just a suggestion, though unsure if realistically a good idea?

The gameplayercontrol.lua script needs a complete re-write, in fact all the functional parts of if it should be moved to a new library (a proper Lua library like utillib!) and then have several lightweight control scripts that can be chosen by the user dependent on what they need.

To customise the main control scripts the user could then simply comment out the parts that don't apply to their game (i.e. if you haven't got any swimming parts just comment it out).

After reading all the thread, I think there is little to say, maybe a few suggestions for now:
1- alt texture
2- to be able to create a hole in the ground without finding water, for example the sewage system of a city.
3- I know that an animation works with frames, but I would like to be able to create 3 or more different animations for the same entity, and that the system uses one randomly, or maybe the one that wants, via LUA as necessary. IE:

;Animationinfo
animmax = 3
anim0 = 0,100
anim1 = 0,100
anim2 = 0,100
;playanimineditor = 0

not all animation techniques in a 3d design program, allow you to enclose 3 or more animations in the same animation, in my case 3ds max. When you try a second animation, you overwrite the first one.

regards

I have given up on the aspect of creating a game with GameGuru has I personally think from when we pledged for
FPS Reloaded and then it was dropped, to then become GameGuru, even with all that work that has been done
with the engine. It still has so much work needing doing to get it to a stage were a real quality game could be
produced.

I have been working away for a year and what I have seen so far looks more like GG is on its way to becoming
the next FPS x10 great promise but just never came to it full fruition due to slow development could not
keep pace with newer games being produced at that time.

So I have decided to stick to just converting old FPSC 9 content for them who want it.
And if nothing of any real big progress to getting a real working standalone game out by the end of
2019 I think I will probably call it a day with GG ever trying to make a game worthy of selling.

This of course is my perspective and may not be shared by others but as the saying goes its my 2p worth
on this issue.

I would love that. Also for things like commenting out jetpack functions. Would help with optimization im assuming too? Having less running on the script.

It`s funny how often that has been forgotten, No idea why.

I mean, Preben has it already working for the AGK loader, and it is something every other engine from the last 10 years has by default. As said, it`s entirely with the designer and his placement of lightsources on how much performance is drained, and it would help a lot of poor souls currently struggeling with the light mapping issues.

Dynamic Shadows would be real nice (death to the light mapper - mooowahahaha)

But that would be a new feature, rather than a bug fix.

Then again if you class the light mapper as a bug, then Dynamic Shadows would be a fix, and not a feature!

Reliquia....

I Agree Reliquia and Ertlov, We need better dynamic lights, with the ability in the properties panel to set each light to cast shadows or not.

And flashlight shadowing only option.

@Lee, Okay okay, may as well be quite frank here. We must fix a software which we paid for? Is this a joke or something? That kind of reply comes across quite snarky.

New people come here with an "easy game maker" in mind only to realise that making a workable game bigger than 2 or 3 levels may not be possible because of unpredictable crashes and bugs which plague this software.

I don't think you know what snarky means <--- perfect example of a snarky comment

No, he wasn't being snarky, he was expressing that some items people will have to wait for because everybody has different priorities and their priority might not be anybody elese's, and he was trying to do it in a tongue in cheek way to keep the mood light.

Hey! Don't you get snarky with me. hahaha.

My bad, then I read that in an entirely different tone.

I thought dynamic shadows (for spotlights and flashlight) would be relatively straight forward to implement but after 40 hours I’ve given up (possibly for good) - needs a Lee or Preben brain for those shadow calcs and approach.

Cheers.

No they come here with a " Game Making for Everyone " tool only to find the tag name changed nearly a year ago

ie 3rd person vs 1st person--

Would this work? Contain only a 3rd person control, and the user can
set the camera as close to behaving like 1st person as they wish-- then
when the camera is essentially at the same location as the head, it would
look like 1st person, but you would still have hands and legs visible, which
some people would work hard to accomplish otherwise- but they would
already be there in 3rd.

Maybe... cause the script to make the body transparent if set to __x__ distance;
a rather short distance? I've seen this type of game behavior elsewhere.

Would not everyone would like this so much? Seems like an option.

SuperClark--

Unfortunately at this time I am in the same boat. Though I can't do modeling!

After 3 projects could never pass stand-alone (well, maybe one- a single level- maybe),
and that's after probably hundreds of hours-- which is fun to plop down models, but
I've stopped compiling games, and just been watching the threads! LOL
I have plans to put one out in the summer though- maybe something will work!
Why, oh why isn't there an Easy Introduction Creator?!

Clone entity via script would be nice to have to.
So you could work with only one and clone it when needed.

Wot like this you mean?

Please Lee some sort of RotateParticle() -- 1 yes, 0 no. Not always we like the particle rotating, but placed in a specific place, static, non animate, in specific position/angle. Thinking in bullet holes here.

How did you do that?

There are two scripts for this available free on the forum here, one by DVader, and the other by AmenMoses, DVader's one has been on here for over two years..

Mine is a rewrite of DVaders original btw, with his permission I might add.

Hmmm... we are talking about the 3rd person view- made... voila... 1st-- maybe call it second person?

Exactly! How- where?! Link? When I experimented with the camera properties- nothing of the sort possible! :~O

Yep. Found it AmenMoses. Probably should -a looked first. You got it posted right there at the top!
Let me try that.

I'd love to see a GTA V style Jedi Knight II style 'press P to switch from 1st to 3rd person view' function in the playercontrol lua

AE

its possible. Just not an easy task.

Hi all

Is there any ETA of the additions of the Explosions work done by AM and GraPhix being released to the Public Preview.

Would be nice to be able to play with these awesome additions

Reliquia....