Would it be possible for a closing statement for 2018 on the development process of GameGuru? and also an idea of going forward what to expect in 2019 ?
There seems to have been a slow down on GitHub recently and the issues seem to be growing, I am pleased with the progress over the past 12 months but am concerned at the slow down on GitHub for the past few weeks.

Would be nice if we could have the Blog back maybe on a monthly basis

Thank you to all whom helped over the past 12 months this community is fantastic all the best for 2019

@GraPhix - I do admire your optimism

Going by the latest DLC Update page - they all be gone on holidays already

But yeah - +100 on the request.

Reliquia....

It would be nice to know what is planned. I wish everyone a great Christmas,

Not quite pre-Christmas but here I am As you guessed, TGC wound down early in December and I myself spent a few extra weeks in January recharging my brain. Started back last Monday and have just about cleared my backlog of emails and meeting duties. I am still looking for freelancers to help on the bugs and tweaks side of the engine which is something I would really like to focus on in 2019, though I don't have a lot of takers at the moment. If you have C++ skills and want to give it a try, we pretty much have an open door policy if you want to have a go.

Another target for 2019 is to change the way we do DLC updates, moving away from batches of PBR textures and more focus on the whole model. This means fewer models each update, but a higher quality, which would include geometry fixing and where necessary, new larger textures and in some cases entirely new model geometry. A perfect example of this thrust is a project GraPhiX himself has kindly agreed to look into which will hopefully transform Mega Pack 3 into a higher quality pack. The issue of better quality model updates was raised a lot by the community in 2018 so this is the course we will be travelling in 2019, though the price you pay for quality is alas, time. I believe we are about 25% into the Mega Pack 3 update, but from the results we have seen so far I think it will be well worth it. To put the time element into context, the updated 'laptop model' from Mega Pack 3 has had new geometry created as shown below:


This is 5 hours of work and counting and does not include the texture work to follow and testing under PBR. And that's just one model. There are 417 entities in Mega Pack 3 and we intend to make sure all of them pass muster. GraPhiX does ask though to resist asking how long it will all take, but rest assured the next Mega Pack 3 will be something worth waiting for! Also, if you are an artist and are interested in getting involved with this, please let us know!

As I have just cleared my plate there are no firm plans for 2019 set in stone yet but I will be planning out the year in the next few weeks. Just before the new year, I did recruit an extra pair of hands to help me with the day to day answering of emails, support, and socials, and helping prepare and announcement updates, and learning the GameGuru source code to slowly chip away at the easier issues found therein. His name is GameGuruEvan and you will find him pretty much everywhere in 2019 as he takes over the easier stuff which frees me up for more lovely coding work. Even though I am still hands on, it makes sense for me to manage a group of coders instead of trying to code everything myself, so if you know anyone in your circle who you rate as a decent C++ coder, send them my email address at lee@thegamecreators.com and say he might have some boon for them in exchange for a little coding

As this is officially my first post of 2019, may I wish everyone in the community a Happy New Year and I hope you have a great time in it!

We have a full year to spend, let's see if we can beat the achievements of 2018

Thanks Lee, Laptop now complete took 11 hours 46 mins, I will try to pick up the pace

2019... need some ideas Lee?

-updated 3rd Person controller, still not possible to change weapons.
Shooting direction for Sidescrollers, still not possible to shoot in direction left or right. You can only shoot in the direction „north“

-updated character creator

-larger, smaller map size... maybe selection when u start a new map....

Happy New Year!

@MooKai -

Patience Grasshopper

Actually it doesn't shoot in any direction, the way shooting works in third person is it damages whatever is beneath the center of the screen (where the cross hair would be in first person) which is why you can shoot through walls etc. because the default "bullet" tracking is from the perspective of the camera and not the character being played.

I'd love to see proper third person, it's something i've been waiting a long time for, but i have a feeling that it's something that if done properly will be a huge job, because they would have to completely rewrite the character controller etc. for it.

You cant now … That was fixed a while back.

no more updates - just fix bugs

Reliquia....

Here here. The first 6 months at least should just be spent finishing all the half-finished additions from the previous 3 years. PBR still isn't properly finished ('real world reflections' specifically, and optimisation), the lightmapper is still sub-par, the improved AI is great but needs more work/more variations to be of use, and I know Lee was working on an update to character importing so that would be cool to see come in later in the year.

AE

I would certainly wait 6 months for a update,if lee spent the time fixing things that need it

Dave

A good look back on github at the little annoying bugs that still are in GG would be great, it's something that really needs to be looked at.

Once that is done a Terrain overhaul would be nice with ability to "Paint" roads and fences onto gradients, better grasses, multiple grasses on the map too. Sound overhaul with proper sound emitters that fire sound in a direction.

A lot I know but all are do-able I hope. Also maybe, just maybe a 64bit version of GG too.

So far though really happy with GG apart from niggling little bugs.

If I could wish me something, I want to do something as a community!

looks like many of us are still waiting for this and that feature or bug fix.
I hope we see some of the "this and thats" 2019
(except a 64bit version.... this would take another few years)

@GraPhiX
Kwai Chang Caine....

Yep I loved that program

Im all for a bug fix extravaganza but not really keen on waiting 6 months for it ..
Bugfix and regular GG updates would be fine though so we could reap the benefit and test all the fixes work
That would keep a momentum going

my wish list is pretty much the same old beating drum over the years

- Bullet holes (at least 5) like FPSC
- Real swimming like in FPSC or better (first person prioritized, 2nd third person)
- Character bleed on geometry like FPSC (if difficult with terrain, make possible with EBE floors and walls)
- Multiple Grass Paint (similar selector as what was started with terrain texture grid picker)
- Improved Entity snapping tools and group selection and placement
- Improved widget (its wonky, i once written up a comprehensive idea for a fix)
- numeric input option for placement, scale and rotation of entities (property panel?)
- 9 slot weapon switching for third person
- More character creator content
- guide or system for implementing user generated content for character creator
- ladders for the player (first person and third person, the animations are there for soldiers)
- Fade shader for enemies that disappear with LOD distance ( + FadeOut(e) , FadeIn(e) LUA commands)
- Remove heart beat sound from if health is less than 100% to less than 60% (its annoying)
- remove image of "100" from health hud for max health and include dynamic maximum health variable
- Entity library search added to engine UI
- skybox blending solution for LUA skybox changing
- footstep sounds for enemies (i understand there are some lua commands in relation to this)
- dynamic shadows (if possible with the limited memory)
- dynamic sun direction,orbit control

Of course bug fixes would be of greater importance than new implementations that might actually bring in new bugs. But its been a while since we had any big features come about. Great to see the particle work being done and i heard there has been some improvements to weapon customization since EAI's pack was released or around that time. But i still feel there are some age-old requests coming from old and new users of GG. Things just kind of feel a bit dry lately. So the atmosphere even in the community has even been effected by it. Would love to see more core engine development news (as addition to the PBR work and updates).

There's an LUA command for that apparently.

I heard this was being worked on before Christmas so shouldn't be too far off.


That you can do already, open up gameplayercontrol.lua and go to line 1727 (or somewhere around there)

I set mine to 30, but you could set yours to 60.

AE

The ability to use any installed Windows fonts for Prompt and PromptLocal would be a nice addition also.

Few of the things I would to see sorted:

Fix 2D image and font display - been broken for ages.
You can spend lots of time making nice custom HUD, but images and font's do not display properly - completely ruins the look of any custom hud.

Fix the grass:
- Popping in and out in places.
- Painting grass is cumbersome, usually goes where it wants rather than where you want it

Fix the issues with the terrain that have been there since 16 texture pipe line was added:
- Banded terrain painting - it is terrible to work with.
- Tall mountain peaks just have the texture stretched over it and it looks horrendous.

Little things like this have been there for ages, and just make for an unpolished experience.

We just keep adding more half baked features, and don't fix any bugs with existing ones.

Having said that - love GG, but it needs TLC.

Reliquia....

What I would like to try in the first half of 2019 is to avoid anything that has a taste of 'feature adds', even if its a call to 'improve' something. As there are quite lot of requests coming through this thread now, can you look at your personal ones, then separate out what you would describe as a pure bug or broken functionality and see if the issue already exists on the GitHub issues tracker, and if not, add it there with as much repro info as possible. That would help me a lot!

It will be tempting for you to classify 'improvements you would like to see' as 'bugs', but the test for that would be "does it do what it does in a stable way, even if what it does is not very much at all". I am also of a mood in 2019 to simply remove (or at least hide) 'half baked' features that the community feels are unfinished as this way the product will only advertise to new users features you all feel are 100% worth having. We can then work on the half-baked stuff in the background and bring them back on-line when the beta testers deem them to be 100% worthy of going back into the product. I would be interested in your personal lists of what features you consider to be half-baked in GameGuru right now. Let the debate begin, there will be consequences

What's wrong with 2D image display?

I've not had any issues with it, i've made plenty of custom huds and they seem to work fine for me.

You mean by positioning? I recently started using the resolution screen size value return commands in LUA to sort this problem out. Its a bit tedious cause you have to consider most common screen sizes but it seems to do the trick.



Swimming -- though i feel partly responsible for it being half-baked

To be fair Lee, and i don't mean this in a disrespectful way, i'm always impressed with how much you get done for one person, but if you were to work this way, you wouldn't have much of an engine left. I'm normally one of the first to stoically defend GameGuru to people that slate it, but i have to admit that there are very few things in this engine that i can hand on heart say do not have bits and pieces that feel as if they've been worked on and gotten to a "good enough" state. That's not entirely your fault, it's our fault too, we're constantly demanding new things, and expecting them quicker, it must be hard for one person to get it done.

Even basic things work, but don't work well. For example; the entity widget, it's very rough and ready, you have no fine control over adjustments so it's very hard to line things up well, it sticks sometimes and just feels awkward to use, and a lot of the time if you are zoomed too close you can accidentally twitch the arrows a bit too hard and it will shoot off a million miles into the distance off the edge of the map, and you have a nightmare finding the entity again. We need some finer control for the widget, for example when moving an object via the widget if we could hold shift to move it in smaller increments, that would make it a hundred times better.

As mentioned above, terrain painting is just awkward with the way it bands, i can understand why it was done this way, to reduce memory and texture footprint, but those bands are just a pain, they make it very difficult to get the right blend, and natural terrain doesn't always work in a linear pattern, so it ends up looking a bit false, and likewise as reliquia said, vetical terrain addition seems to stretch the planes without subdividing, so if you get a near vertical cliff it stretches the textures horribly. On a similar note, grass painting isn't exactly perfect, if the angle of the terrain is wrong we quite often get floating grass, and it's difficult to get a good gradient blend from heavy grass to spotty grass, it also feels a little more uniform than it should be, not enough variation in height and spacing.

Another big issue for me and many others is the light mapper, the disparity and difference between light mapped and dynamic entities is too great, considering we have to use dynamic entities for interaction, a dynamic entity and a light mapped entity should look as close to each other as possible, otherwise they will look out of place, at the moment it's not the case, you get one looking a lot lighter than the other, and when you're using entities that are meant to be snapped together you get an obvious line where they meet.

Again, another feature that is not quite right, although i am impressed so far and it is very good, is PBR, little touches, for example the reflections, at the moment it only reflects the terrain, that's all well and good, and again i understand you're trying to keep the footprint down, but having terrain reflect on an object in an indoor scene just looks out of place, i know we can make our own cube maps, but that can only work to a certain degree, after which it becomes a chore, because you would have to make a cube map for every reflective object in your scene, and for it to look right each object would need an individual cube map, so if you have say eight of the same object in the scene you would have to duplicate the models in different folders with different cube maps to make it looks right, and so forth.

I'm glad you are looking at fixing features that are "half baked", it is well overdue, but it's going to be a large task, and removing them until you can get around to fixing them is going to have a serious detrimental effect.

Holding Ctrl key whilst moving the widget is supposed to give fine control but even that is a bit hit and miss sometimes, the biggest offender for me is the scaling though.

I agree completely with Belidos

Pcs

Remove what ?
To be honest I dont see anything that warrents total removal ...
Just fixing to be honest.

Just went through the bugs list .. 245 altogether

107 are enhancements
140 actual reported bugs and many are repeated along with the fact that one fix may fix 5 other related bugs at the same time ….. That's where I would start ..

Yes don’t remove,just fix what we have

Dave

I have a lot problems with scaling, rotating and positioning with the widget (at times). Really it depends on the angle im looking at it.. though sometimes not at all? It can be quite wonky at times, but its one of the most useful tools. Scaling is a nightmare for me because there is no shortcut key for it. For example rotations and positioning we have keys for those, but not scaling. So we are forced to use the widget for it and it just never works probably for me.



I use the same tools as Bethesda and i tried to bring up a topic around how to implement a 16 terrain palette that works well with 32 bit memory limitations. It allowed for virtually unlimited texture options for a map and about 3 depths for blending. I believe Game Guru actually uses more than what the Bethesda tool allows. Cause it will prevent you from painting too many layers in a single area but allow for you to paint really limitless textures elsewhere on the same map.



Personally i dont think its a good idea to remove them as most of the 'half baked" features are ones we are all using in our current projects. I also believe that most might consider what is 'half baked' to be a great percentage of the whole of the engine. Lots of anticipated improvements. I'd say even the third person mode is in this category.

Tri-planar texture mapping for terrain is switched off in settings.fx, but can be enabled by adding // to FASTROCKTEXTURE (and recompile shaders)

I think one person's 'good enough' might equal another's 'half baked' that is the same as yet another's 'very good', so I would always fix forward rather than remove ... better to iterate towards 'perfection' than wait 6+ months for it.

Cheers.

These gems of information should be in one place ,like a tips and tricks thread they just get forgotten

Dave

Great thread, and I am more than happy to hear something from the official side again.

I also have to agree with belidos and I want to add some thoughts that come to my mind as well.

1: Performance!

Yes, am I really the only one who mentioned it? It has indeed gotten way better but I can say that I hit the limit frequently. No matter what workarounds I use and what shader's I turn off, it is still impossible to create decent sized maps with decent amounts of detail.
Here is a prime example of something I have been working on recently.
basically this is the maximum I can do right now:


2: AI

It was mentioned bevore and I have to agree that the AI has improved too, but it still needs a bit work.

3: Bugfixes over added features.

We all want gameguru to work. We all love gameguru and I still have tons of fun with it but there are many small issues preventing users from progressing. The Github Issues List is growing and I think gameguru deserves to be "fixed".

4: Communication between TGC and gg users

It's 2 am, sorry for not going into detail further. I am glad that this thread exists and I hope that the communication will get better and more frequent again. Keep us updated, talk to us! Often we are wondering whats going on..
I think a monthly blog or something would be a great idea.

5: Dont remove features

And please, for the love of god, DONT remove features!
Think of those ppl that actually try to make games with this engine and maybe rely on some features!
Work on them, eventually fix or improve them, but please dont REMOVE them. I think most users will agree.



totally agree. cybernescence's knowledge about the shader and how it works is way to valuable for it to be scattered around in the dephts of the forum.

Now I can go sleep. Have a good night and I wanna say a big thank you to all the busy guys fixing up gameguru

Have a great year 2019!

- Duchenkuke

What really needs to happen is the code needs a major clean up.

It needs to be made modular to stop problems like knock on effects where fixing one thing breaks something else totally unrelated.

Local Variables should be used with passed values where possible rather than global variable pools that can easily be altered in error by unrelated code.

Proper clean-up of variables after use would help to compiler optimise things and reduce the chance of memory leakage.


Good modularity is better for co-operative development as they can concentrate on their particular area with out the constant risk of breaking someone else's code


also using a global variable pool forces the compiler to use long and indirect addressing to access them which is a lot slower than local(short) addressing and stack use.


Also the lack of modularity seems to lead to patchcode where for example a varible is forced into a specific value range when it should never have gotten out of that range in the first place(indication the cause of the orignal error was never found).

I have reason to believe this software was well designed by the standards of the day but it has been allowed to evolve uncontrollably for far to long. I needs now to be forced into a strong well defined frame work and pruned quite ruthlessly if it is to remain viable in the future.


Lee is a very able programmer but he currently is the only person who knows the code well enough to have any hope of tracing the more complex problems. Maybe it time for him become more of a project manager for GG. GG is now too big a beast for one man. May be his last and greatest project as sole programmer and chief bottle washer for GG he could make it more manageable for his troops.

Remember no General won a battle sitting in the trenches up to his neck in mud no matter how hard he shovelled it.

I do love the sound of mixed metaphors in the morning.


All I meant to say was the code needs to be restructured for more reliability, maintainable and expandability.


But I was in the mood for a rant its turning out to be one of those years (already!).

Actually there is one thing I would remove …
the " Put your Logo here " screens .. Once you have made your " 40 " Screen Custom Menu that last thing you want is another 12 which at that point are pretty useless

LOUDER FOR THE PEOPLE IN THE BACK RATALL!

what duke has shown shows gameguru's got a pretty solid foundation so far, the problem is it's inability to actually produce a sizeable complete game of any level of detail. once the quality and the mapsize gets high, so too does the chance of error. the opposite effect happens on the frame rate, which plummets down to the "below 80s" when the level is about 2/3rd of the way done. There is a reason we only see puzzle games and flashlight-lit horrorshooters representing GG on steam (besides asset flips) and that is that GG simply cannot handle much more than that specific minimalist approach.

also, the whole "PBR" thing in my opinion was a fiasco. PBR makes for our game assets to use twice the texture memory (when they aready used plenty more than enough before), and now our lightmapper is largely broken because of it. There is no semblance of proper reflections and without the ability to even bake static lights, it is clear we have stepped back from GG X9 which was graphically more capable than the X11 we have now.

look at FPSC X9, learn from the success there. You provided the tools for anyone to make a game, but admitted there were limitations (so people worked within them) and instead of focusing on providing features that are also found on AAA game engine lists, you made features like:

an easy scripting language,
intuitive yet powerful editing/editor navigation tools,
a simple but full featured wysiwyg process for setting up a game build with music, levels, skies, and quality settings
a large quantity of generally useful stock content for any game


then look at FPSC X10, which was a graphical improvement at the cost of lots of other FPSC features, something that died very quickly. You have to take a look at what your major demographic is looking for from your software. That is not producing the next graphically astounding big budget blockbuster, but rather to have a simple and STABLE tool with which they can create their own indie game, all in one place.

i feel like PBR X11 gameguru is the FPSC X10 of gameguru. gameguru games have never looked pretty enough to warrant requiring a new amazing pc to run them, and yet anything less than a gtx1080 and i7 will frequently cause gameguru to go unplayable.

if you had stopped at GG x9 5/12 and from that point on only worked on creating the most capable X9 engine you could; one that was a marked step up from FPSC in every way, GG would be miles ahead of where it is now. as it is, I feel effort has been miss-invested for a long time

if instead of gameguru, you had made FPSC X9 a 64 bit engine, and doubled the mapsize (and maybe rewrote it in C++ too like you did with GG) i honestly feel like it would be a major contender amongst indies to this day. Hindsight is always 20/20 but try to move in the right direction.

on the topic of PBR, my understanding is this is more popular among 64-bit engines. I upload content with the unity store and PBR is often mentioned as being highly attractive sales wise. But with a 32 bit engine it really uses a lot more memory. But I dont want to knock it in any way as i understand it helps finance development and the work does in deed look great. Just from a personal level i want to make a game that is stable and fun to play, above graphics.

i think for a lot of hobbyists the PBR stuff is great. As they are just making attractive scenes and video recordings or single map experiences. That is reflected with sales. For me, ive actually been crunching my textures down to 1024x1024 and 512x512. Very few go any higher unless im atlasing. For performance sake and memory cap prevention. We shouldn't forget we are working with 32 bit engine here with limited memory. So we should work within the means if we are to take anything serious with game development with the software.

With this said however, its up to the user how he/she wishes to uses the assets provided or bought. can always divide the textures down and disable PBR if necessary.

On a positive note, i think the work the contributors have done over on the github is amazing last year. Also the AI improvements was quite refreshing.

Dynamic shadows actually save memory at the cost of GPU / render speed.

If we had dynamic light sources cast proper shadows, we would`t need light baking, and light-baked maps eat hundreds of megabytes easily.

Dynamic lights cast dynamic shadows. Thats the golden rule since 2008. The amount of FPS sacrifice is simply scalable by the level designer -> amount of lights, type (spot / omnipoint) range.

I think the reason nobody has mentioned it is because firstly Lee is aware of optimisation and the need for better performance, and secondly it's something that shouldn't need mentioning, it's something that any developer should be striving for with every line of code he or she writes, it should be a given that the dev or devs are always trying to tweak performance as they develop, and finally a lot of the bugs and issues that we have would very likely help with performance if fixed too.



I agree, not so much on the actual combat side of things, that part is much improved, but definitely on the AI states, such as when it is not aggro'd and hasn't triggered a combat reaction, it needs to be in an unarmed or relaxed pose, we need extra status such as an alert state which makes the character stop and look around, maybe pull out his weapon, when he hears a sound or sees movement in the distance. What we really need is a way to create an AI script that has all the states in it, and can be set to triggered by options in the properties panel, that way we can use just one AI for both armed, unarmed, and neutral characters.

YES, yes and YES !




Of course! How was I able to forget that...

Some great thoughts there and I have to say I agree with them all. Dynamic shadows would be awesome addition, yes the widget needs a good looking at too, and as we have an extract, what ever happened to the copy and paste of a group of entities, eg: building with contents, just hightlight the lot and copy and paste to a new map position.

I know Preben was doing early work with flashlight shadowing, what happened to that???

Well, Bugsy makes some valid points there me thinks, but too much done to go back now. Like everyone else I would love to see new features. But lets just polish what is there now first.


Noooo please don't remove or hide stuff that's there - lets just fix it where broken, and finish where incomplete.

When I say 'half baked' I mean that a given feature has been added, but not polished and may be considered buggy since it is either difficult to work with or does not work as it should.
- 16 Terrain is a classic example - it is tedious to work with. The old method was fun\easy to work with, and blended way better than the new imo.
- Grass has been buggy since even before DX11, and is also harder to work with now.


Stand-Alone Menu screens are broken - they detract from polished experience.
Reported here: Menu\Hud pixel issue #423

Fonts display poorly:
Reported here: Custom Hud - Fonts display poorly #231

Open the below images:
-The large one shows how all fonts are not displayed properly.
-The smaller one is using the old Image Display method, it may be OK when displayed as a sprite (haven't tried it) but the feature is there, so it should work properly.

------------
However I really think Lee has created an awesome tool in Game Guru - let's make it more awesome!
------------

Reliquia....

Except the 12 put your logo here screens

Bulletpoint recap of what is most needed this year, gathered from longer posts above and my input too

* Performance and stability. While its fun to tinker with tech demos, the point is to make full games...that actually run. Make this happen.
* Lighting: It needs to work, it should not murder the game in terms of memory limitations and I can't believe its still an issue in a 3d engine past the year 2000.
* Memory Managment and loading times: We made improvments here but there is a long way to go still.
* In menu game settings. Allow the end user to adjust resolution, visual quality and controls. How is this not already in?
* Both "rendering pipelines" should work. We have the PBR update, its here despite how questionable its usefulness is. However, currently reverting to the old shaders (DNS) is broken. Objects are not displayed correctly and lightmapping ain't working too hot either. Given that GG's library consists mostly of DNS models (or just a diffuse slapped on) and so is most content available online its absolutely necessary that the engine renders those materials at least somewhat competently.

Things that would be cool but are optional:

* We have an EBE. Okay. Why don't we have a simple brush system? (its a stretch and a whole new feature but I had to bring it up.)
* Search function for the entitie library. I don't need it personally but a ton of other users do.
* A saturation bar, given that we already have contrast. (TAB) I bet there are a lot of dilettants that would like to use this for generic horro games
* Where is bond1 at with his state of the art water effects? I've been waiting on this for years now.

To reiterate: Performance! Stability! We want to make games that have stuff happen in them. Dynamic entities and characters should use up less FPS, the postprocessing, especially just the bloom shader should use up less FPS, the terrain is a monstrous resource hog too. Water seems fine. Also after all the trauma some of us suffered from FPSC, we don't want to work on our games only to have it end up being a runtime error.

So happy new year, godspeed and lets get this engine where we want it to be.



yes



-Wolf

Just here to share a list of what I would like to see:
-The abillity to finish a game without massive performance issues, tons of bugs, crashes, etc.
-The lightmapper is currently broken, it's really not usable at all. A lot of models get out of scale or just don't reflect light properly.

For the rest I completely agree with Wolf and Bugsy. I can live with the graphics being out of standards, but if I can't finish a product that at least has some form of stability and a decent performance, I wouldn't sell it. GameGuru is an amazing product, but I feel like the progress in 2018 has been very slow (also because of the dx11 stuff). I'm aware that I haven't contributed to GameGuru apart from using it, but I just wanted to share this.

With that said, I'd like to give a massive thumbs up to the community, and to Lee for sticking with GameGuru.


Thanks,

@Lee, thanks for putting on the flameproof coat to brave the forums. I have enormous respect for the product you've made, despite the misgivings I may have with respect to what's going on with it at the moment.

As someone who's had the assiduous task of practically living in GameGuru for the past 10 months as I write my book (which is nearly ready to go to the publisher!) I've learned a lot. A lot more than I think most people have with respect to GameGuru. There's tons of information on GameGuru and initially my goal was the simply aggregate the information into one location so people could have it.

I've spent hours pouring through C++ code to find information on simple functions that had no documentation. Debugged Lua and traced out AI code simply to properly write how things will react. I've learned how to manipulate shaders and functions that exist within GameGuru but are only known to a select group of people. Things that seem simple often are not.

There's a LOT of things going on under the hood for GameGuru. Things that can basically be dismissed for most as 'that functionality exists' but no one knows how to use. That said, there's also a LOT that needs repaired but is probably could be done in three to six months. So here's my big hitter list of things that need fixed, for what it's worth.

You can divide this into two separate categories.
1) Performance.
2) Function.

Starting with performance:
-- Dynamic lighting needs to shine. I'm happy to see that it has vastly been overhauled in the past 6 months. That said it still:
=== Shines through walls
=== Doesn't cast shadows the way it should
=== Doesn't properly occlude itself based on distance or location.
All of these items would really massively improve the way dynamic light functions.
-- Static lighting eats too many calories. Default settings in the setup.ini file essentially ensure that any level bigger than a simple 'few buildings and objects' will either crash or consume too much memory to function.
-- Internal graphics cards need either excluded from use or have a further restricted memory mode to prevent overflow. I realize a lot of GG users are on lower end machines but when you are running a 32bit application on 4GB of ram and using onboard video that shares video memory with system ram you are GOING to have problems. Either say 'no, you can't do this' or find a way to put them in a walled garden from a memory standpoint.
-- Objects need tuned for 'out of the box performance'. Why are trees animated, when we know that they are massive consumers of in-game performance? Why aren't there 'performance friendly' objects that are physics and collisions disabled? These are things that exist and have existed within GameGuru but are known killers of framerate. Literally the moment you spray 100 trees down, the entire game bogs down to a practically unplayable state.
-- The game engine needs to optimize end products more. There's no optimization phase in standalone generation and it's utterly destructive for end users. They produce something in the editor that's a total clump of materials and memory which then doesn't run - and they they immediately complain about. For reference, my chapter on optimization is 8000+ words. If you exclude my appendixes, that makes it nearly 8% of the book's total content. It's by far one of the largest chapters because of how MANY things the end user needs to keep in mind just to get a game that runs well.
-- Memory management: what's to say that hasn't already been said? It's been significantly improved - until you do something like lightmap or anything that becomes intensive memory-wise. Lua code uses too many globals out of the box and as a result devours further performance and memory.
-- Draw calls - a better way to track this would be ideal, along with some better measurements of how they are affecting FPS/gameplay. With PBR adding nearly quadruple the draw calls per object, this is of more than minor consequence, IMHO.
-- The widget. Look, I can tell you flat out at least part of the problem with the widget is a math error.
Please read this Lee, if you read nothing else.

The widget has a math error if your object is facing the opposite direction. It causes it to go exponential on one side and act 'normally' on the other. I took a cursory look at the code and couldn't find it, but I am positive this is what is happening after much in-editor testing and work.

Moving on to functionality:
-- The editor. Lee, you saw my email previously on this. There's TOO MUCH that you can do outside of the editor for this to be an easy game maker.
=== Please add incremental widget functionality as stated by previous posters. It would go miles towards functionality.
=== Why are 90% of the FPE settings something you cannot toggle inside of the editor?
=== Why isn't the third party setup.ini editor not duplicated and made part of the game engine?
=== Why can't we pass variables to Lua from the properties pane?
=== optimally I'd see a dynamic menu at the top (as discussed in email), along with command menus that have:
***** A way to compile/modify shaders built in
***** A way to access 'advanced' FPE properties from the editor
***** Vastly more detailed memory usage information
***** A way to properly search the entity list. Simple meta tagging and a basic in-editor search would go MILES towards functionality.
***** AN AUTOSAVE FEATURE FOR THE LOVE OF ALL THAT'S HOLY

-- Third party programs need to be incorporated into the game engine. I'm enormously proud of the work the community had done in this regard but now it's time to bring it home.
***** A heightmapper built in
***** A setup.ini editor built in
***** Styleguru or similar built in.
***** A notepad++ or similar lua editor built in (perhaps a link to it inside of the engine via command menu).
-- Just give us an 'advanced' menu where we can edit as much as possible from inside the editor. Please. I realize you are trying to cater to 'anyone can pick up and use this' but how far do you intend them to go when you cut them off at the knees within the confines of the editor?
-- The vegetation system is one of the beast features of this engine. Please let us spray up to 4 types of vegetation. This would solve the issues of trees eating memory (spray trees like DK does and it becomes a non-issue) and would give us greatly enhanced function as developers!

It simply doesn't matter that people like me know how to do workarounds to these things - the average user DOES NOT! The entire system is underscored by the fact that it works fine if you *ONLY* build 10 or less objects in it. If you actually sit down and build a massive level, you will find it goes from being an easy game maker to a difficult one. You have to constantly go out and adjust FPE files, edit things, spray them, configure them to occlude properly so they don't pop, tune setup.ini, religiously save your game and more.

I hope, truly, that everyone understands what a monumental work this product is. It's come a long way with the improved community involvement and now needs some love from the originator of it to help get it to a place where it can really shine. I am hoping after I'm done with the book I won't be so burned out that I don't touch GG for a long period. I'm hoping I can dig into the C code and make adjustments myself to improve things but I can't be sure of that. So I'm putting my thoughts out here on this in the hope that you are receptive towards this Lee and will re prioritize this to make this engine as good as it has the potential to be.

This is something i respectfully disagree with, not that it's needed, it is needed if you want to have a game that performs well, but that it should be provided by TGC.

All of this is down to the models and their configuration within GameGuru, it is all stuff the user should be doing to optimise his/her game, not the engine creators, and some of it like having animated trees are personal dev choices, yes some of the default models could have been more optimised, but to be fair should people really be using default models for a release game?

Isn't free models being recycled endlessly one of the biggest things the critics complain about in the indie industry?

Personally, i view the models that come with GameGuru as placeholder examples, some nice freebies, but not something i'm actually going to use if i release a game.

DLC's on the other hand, i absolutely agree are completely different, they need to be optimised properly off the bat.

Almost everything else you posted i 100% agree on, especially adding every option from game settings to shader settings needs to be accessible from inside gameguru, we shouldn't have to be editing files, and those settings should only apply to the current map, one of my biggest issues with settings is having to apply them to every map, or keep editing the file every time i switch maps. Lee mentioned a while back that he was working on a system so we could have projects separate, with maps associated within the projects, and separate settings etc. but i haven't seen anything since.

Bolt Action Gaming's post is very comprehensive!
@Belidos:


This is true in theory. However in practice every commercial GG release so far has unedited stock content within. Store content that I know having a way too high texture resolution usually shows up unchanged as well.
These things need to be clearly communicated. Especially now that media is being overhauled, made higher poly and higher res.
I too view stock content as something to work with and to learn from but the majority of GG users just drag and drop so I agree with BAG that they should be optimized by default while having the option to use animations for example for advanced users.



-Wolf