Hi All,

For those who missed the live broadcast and chat, here is a recording of the video, and below I have provided answers to all the questions asked during the live chat:



And now your answers:

Q> ​How far will the charactor creator go and will there be a form of logic system and if yes how advanced will it be?
A> The version of the Character Creator you will find in Alpha Build 1 will be the one we release for MAX, no significant additions to the system we have right now. For more information, check out the previous sneak peeks and live broadcast recordings.

Q> Are the textures PBR in the new tool?
A> The textures you use in the new tool will be mapped to a virtual texture when you paint them down, and the whole terrain will be rendered with the Wicked Engine renderer which is nothing but PBR. We see the importance of some surface details when painting terrain down, but we want to see it in action before deciding how much surface detail to paint (i.e. can normals be autogenerated to reduce virtual texture storage). Watch this space, but we will be ensuring the terrain has the same PBR quality as the other assets in your scene.

Q> ​The new texturing system is worth buying it again already!
A> We took a lot of feedback from the first terrain system, and have a good handle on what is needed for users to go to that next level.

Q> The new painting system seems massive good work Lee... seems you this time really want to give us something great like GG itself and GG community deserve...
A> Yes indeed, our community have demonstrated incredible patience over the years, and we hope MAX will deliver on some very long standing expectations.

Q> Please add more "undo" steps.. not only one.
A> The Undo System we have in mind will capture a series of steps from the painting activity, so several mistakes can be reversed. We will not be storing undo history with the level, so the moment you save your file, leave the software and relaunch/reload, the undo buffer is cleared.

Q> ​I wonder if this allows destructible terrain. craters etc
A> There are no plans for destructible terrain or craters, the terrain painting is done at edit time and them compressed as virtual texture files for last and efficient rendering. You could achieve some dynamic effects such as making a decal crater texture visible using an entity, but this will not be part of the terrain system.

Q> What's the bone level details how many can be added. eg animal bone support?
A> My 'current' understanding is that the Wicked Engine animation supports only four bones per vertex, but you can still do plenty with this limitation and if you are a 3D modeller, creating animals and importing them is no problem.

Q> Blueprint system?
A> There are no plans to reproduce the Unreal Blueprint System in GameGuru MAX. For now, we use LUA scripting which is a relatively easy script to learn and gives you a huge amount of in-game functionality for those willing to do a little coding.

Q> ​Sweet terrain textures. Plus show multi-vegetation for our vegitarianarians? When is this video related Alpha released?
A> Multi-veg (i.e. grass) will happen after the terrain painting is complete and performant. The next alpha build will be based on the version you have seen in the live broadcast, so watch this space for an announcement of it's release.

Q> Will GGMax have a proper grid and snapping system similar to other 3D programs?
A> We plan to retain the grid system in Classic which used a fixed grid and a clever snap mode which detects the bounding boxes of entities to magnetise entities together, though we will be allowing the fixed grid to be adjustable so you can bring in different models that use a different grid dimension.

Q> I have a quest ... Will i be able to sideload to use it ?
A> You can use the Oculus Quest Link system to connect your Quest headset to the Oculus Main Software, and use the OpenXR runtime available from Oculus to play GameGuru MAX VR content through your Quest.

Q> ​How easy will it be to import animated characters, and set up their animations?
A> Thanks to AssImp (Asset Importer), we will have access to most of the data from a model, including it's rigging and animation, and we have already had success with X and GLTF models coming in rigged and animating. For animation setup, we will be using an animation stack system so you can bring in only the animations you need for your model, and then use LUA scripting to play those animations as you require. For MAX we will be leaning towards less hard-coded behavior and more exposure of the logic via scripts.

Q> ​When is the next alpha?
A> No confirmed release date, but definately this month.

Q> Why was gg classic github locked
A> Just checked and it is still there (https://github.com/TheGameCreators/GameGuruRepo). We have moved the Wicked Engine version onto a private thread while we do the development of course.

Q> Shouldn't the grid be set to powers of two, not set to 100?
A> With manual adjustment of the grid dimension, you can set a power of two if you need this.

Q> ​Will we get a vertex snap?
A> No plans to add vertex snap to MAX, only overall boundbox snap per entity.

Q> ​When is multi- veg premiered?
A> We will be able to reveal multi-veg grass painting once we are happy with the terrain painting. The grass painting does relate to the terrain in that the grass positions are stored in a similar way to the terrain texture detail, but more will be revealed when we have a prototype to play with.

Q> You gonna add a better AI?
A> There are no plans to add additional AI to GameGuru MAX, and instead keep the scripting system open so you can add your own AI logic for your games. We will add scripts as required to improve out of the box behaviors, but there is no significant additions planned.

Q> Can we get a projectile script to attach to objects, e.g. Canon balls or arrows so we can see the projectile launch fly and land please?
A> There are no plans to add projectile scripts to attach to objects, or to produce cannon balls or arrows. You will be able to do a version of this using LUA scripting but you will need some coding experience to create an effect close to what you would expect from a modern game.

Thanks again for all your questions and I look forward to bringing you another live broadcast in two weeks time. In the meantime feel free to use this forum thread to discuss the content of the recorded broadcast and ask follow-up questions. As always, happy game making!

i will be there

I will catch it a little later this evening after work. Thanks Lee.

" Can we get a projectile script to attach to objects, e.g. Canon balls or arrows so we can see the projectile launch fly and land please?"

This has already been asked before in these forums, and answered also.
What you are looking for mostly is the "particles" system;
https://forum.game-guru.com/thread/220140

And maybe you will need to trace the projectile;
https://forum.game-guru.com/thread/220802

Script the projectile and particles yourself, and it's all good.

Ok Thanks Lee
I am familier with Oculus link and use it for steam games all the time but i ordered the downloadable version so was not sure if it would still work that way without the need of some kind of sideload.

Looks Great ! Thanks Lee!

The terrain painting system looks really nice so far.

@ Lee
Not sure if you said something about standalone in GGMax, I guess it will be the same as in GG, anyway, I hope a complete standalone system, without the GG issues.

Really great work. Things seem to be going quite smoothly. I really like the look of that terrain painting system.

This is far far more than I expected at this early stage, fantastic stuff Lee & Co.

I'll be frank, one of the things I don't like in Classic is the grid system.

Firstly, I would like a visible grid, if possible. It's good to be able to see what you're snapping too and having a visible grid that represents what your snapping is set to.

Secondly, the current grid in Classic really only allows for two snapping adjustments - a default snapping and the "magnetized" one you mentioned. We really need a system where we can set our own snapping (more on this below). You say it's going to be adjustable. Good. How so? Any details about this might elevate concern over snapping in GameGuru Classic.

Thirdly, I don't like the very non-standard way you have to turn on/off snapping and adjust it - by repeatedly clicking a button to turn on and cycle through the snapping options (pressing the "B" key). Why go with such an non-standard way of doing things? Instead, offering a toggle on the UI to turn snapping on/off. And then offer a box where end-users can either select a snapping increment or can manually type one in.



While this may not be necessary any longer, many games editors use a power of two grid (8 minor grid squares to a single major grid square) that can be set only to power of two increments (2, 4, 8, 16, 32, 64, 128, 256, 512 ...). This is because textures/materials should be designed according to a power of two due to video card memory requirements. It would be nice if there were a simple method to ensure the grid is set to a specific power of two of the end-user wants/needs it. Again, as pointed out above, I hope that all of this ability to adjust the grid is not hidden behind having to keep tapping the "B" button, cycling through snapping options, but that snapping is added to the GameGuru MAX GUI (a toggle to turn on/off snapping and a numeric entry box to set the size, etc.).

@Lee - [Question]

Will the raycast system be the same in GG Max as classic, as I have scripts and some in the store that rely on the raycasting, ie my note script uses it. ? Thanks.

hope we see some weapons in action in the next video

Great job Lee - very impressed with terrain direction - no more banding will be awesome indeed.

I build all my models with the current GG Classic grid system in mind, so they go together easily in the engine, so I have no problems with current grid method in GG.
However it would be nice if the various Marker points keep their positions, rather than the way they work now. So if you plonk one down and then pageup to a higher position they stay there. Currently they like to go all over the place if they are not on the ground level.

All in all great progress

OldFlak....

And that's great. However, there are a lot of game models out there built for a power of two system. Not only that, some of us, who have been doing this for some time for other systems, may already have a trove of assets at our disposal, not built for GameGuru's grid because they were not originally created for GameGuru. So, I believe it would be nice if MAX had a more "traditional" grid system. I see little benefit in being different here.

@Agent_Arts. I think the power of 2 relationship is more important for 2D applications than 3D ones. Model geometry is not a factor, but you are correct about textures being faster at power of 2 values.

I think a simple setting for the grid size would be the best way forward. I'm happy with the b key myself to toggle between modes, been using GG so long it's automatic, but an additional menu option and a way to alter the grid size would be a welcome addition. Being able to adjust the grid to the size of my objects is preferable to the other way round. A visible grid shouldn't be difficult for pro coders and would also make things easier a lot easier to plan out. You could see at a glance how to space things out, whereas without a grid you are guesstimating.

Anyone else think the hands remind them of Bioshock? When you first get your powers ;p

Yes, it's primarily for textures/materials, but this applies to models, too, if you want to not have your textures/materials stretch, etc. So, you build pieces, like floor tiles, that are also a power of two to properly (and perfectly) display the texture/material made for them. This is why many 3D editors for games use a non-standard grid ... a power of two grid that has EIGHT subdivisions instead of ten. If you set each grid subdivision to 16, then you know that each major grid square is exactly 128 x 128. If you set each to 64, then you know that each major grid square is 512. As a result, you can lay out geometry properly so that your power of two texture/materials display perfectly in-game.

EDIT

Apparently I am too "old school". Power of two grids and all that, while still used in many places, are no longer the thing. Leadwerks still uses a power of two grid, so does S2 Engine HD. Apparently Unreal (and I am guessing Unity) does not, but uses something that translates more directly to real world measurements.

@Agent_Arts. Hah! I'm old school as well I know modern video cards work fine with any old texture size, but I still always use correct texture sizes. I'm sure even monster video cards probably work faster with them. Phones and mobile devices though, still need power of 2 textures to run remotely well (some will not even run without them).

I've never worried too much about stretching textures, but I'm not a pro artist. As long as it looks okay Certainly something to think about though! It would be interesting to see how much difference it makes (beyond huge objects looking like Bantha Poodoo if your texture is too small).

I'd love to see texture atlas files supported in some way. It would for certain give a boost in speed in certain areas (notably sprite based stuff, but for certain could improve 3D as well if you have some objects you don't need huge textures with and are used a lot in game).

I wrote this last year and although it still needs some work on the control method for mobile devices (never great) I'd say it's fairly old school Hail the Invaders!

@DVader - Sure, video cards will work with textures of any size. That's not the issue. The issue is memory consumption. If a texture is something like 415 x 430, it will use memory for a 512 x 512 texture (it will use the next size up). Therefore, if you do this a lot, you end up with a lot of video card memory being used for ... well ... nothing. To keep this from happening, we need to get as much texture in a power of two space as we can. That way we can control the memory being used in the video card.

@Argent_Arts. I'm not disputing that. I agree on texture sizes, I wouldn't even consider using a non power of 2 these days. I was only saying that modern GPU's run them, whereas at one point (still the case with mobiles) you HAD to use them. There was no choice. All game makers should use them if they have any clue what they are doing and want the best performance possible!

I just wish I could still use 256 colour or less if I wanted ;p That hasn't been supported for years now Modern cards just won't drop to those display modes. Yeah I can still make an image 256 colour, but I'm not getting the performance gain as you would back in 90's.

I would love it if TGC would include a bunch of color grading tools so we could emulate the look of 90s games if we wanted to - as well as black and white noir, static, vignettes, etc.

Me too. I myself have to use Ciber's shader to get this effect on my last level, in GGMax.

That's because back then CPU's and Graphics chips were 8 bit native, nowadays CPU's are 64 bit and many GPU's are 128 bit or more!

Internally modern GPUs work on Quads, basically 4 x 32 bit words representing 4 pixels (R,G,B + Alpha) at once, i.e. each individual memory access is sucking in 4 pixels, and the pipeline is optimised to work with streams of them.

The AMD top end cards actually have a 256 bit bus so suck in 8 pixels worth per memory access when working with textures.

Working with 8 bit colour maps would actually slow down a modern GPU considerably as it would need to internally expand them to Quads before it could work with them.

... and I'm glad. I hated working with 256 color palettes like back in the day ... creating new palettes for new levels and all that. It was fun ... for a time ... but was, ultimately, just a PITA.

You mean back then they were good ;p At least back then a cards speed was mostly down to the card, now it's highly dependant on driver software. If not AMD would have ruled thew roost for some time.

Edit - Although I really miss colour cycling, it was super useful back in the Amiga days

Yeah, just to say I was not disagreeing with you .
Certainly MAX would benefit from an improved grid system, I was just mentioning that as a prelude to my request for making markers stay where they are put.

A flexible grid system is a no-brainer, preferably one the game developer can tweak to his desire. Power of two textures, while not required these days, are still best for anything mobile, and is easily a better use of texture\memory resources, no matter what platform is targeted.

OldFlak....