I am relatively new to GameGuru never actually new much about it before i purchased it other than briefly looking up games and seeing bad reviews about it mainly on steam. As most people I decided to look up solid examples on youtube/online of games made with it and came across some pretty decent examples. Enough so that i thought "ok worth a shot here".

What many of these games do not really show in gameplay footage is the bad loading times when running the game in standalone. Extremely bad so much so that this is the sole downfall to GameGuru and is nothing more than a learning tool. No one should be releasing games for sale with this engine it just hurts the product and most of all the community.

Initial thoughts were positive and still are. I have had GameGuru for less than a week but for the most part have managed to grasp on a basic level the structure of its system. And at the same time what we should really be expecting as paying customers.

Not to take away from the product I like it but at the same time it is lacking in some of the core fundamental areas. Again one being load times every single game released on GameGuru Classic will have this problem some more than others. And nobody who attempts to play a game made on here will appreciate this and any game is doomed to fail.
As i am writing this i almost feel like GameGuru abreviated as GG is an acronym for "Good game" meant in a humorous way like its all by design.

Put it this way if i knew what i have learned about classic and its downfalls, the fact the your first engine is over what 10 years old? I probably would not of bought the product tbh. I already bought max pre-order before i knew about some of the problems in the existing engine. Its fine i will cut my loss cbf refund because cannot be bothered and i am happy to use this product as a learning tool.

What is going to be done with GameGuru max?? and standalone loading times?. Because as it stands so far all i have seen is GameGuru reskin 3.0 and have not actually seen much about said area concerning the new engine and loading times for a finished game.

Well considering max is actually entirely new product using a 3rd party rendering engine, it isn't simply a reskin. It is an entirely new 64bit product still in development.

Ignoring the fact that fallout 4, the witcher 3, bloodborne, grand theft auto 5, borderlands 3 all had long loading times even battlefield games had long loading times is the automatic assumption that gameguru not having the same class as those should be loading faster.Definitely not it is a slower engine with much weaker technology compared to engines used in those commercial games where is had several 100 people working on those projects, compared to a singular individual that worked on classic. ?

The bigger issue is development of the game, design layout among other things that drastically increase loading times.With a weaker engine trying to apply the same massively scaled levels isn't the right way to go about it either, as with any game engine there are limitations and throwing every entity you have in your library is a recipe for long loading times. Considering you can break up a level into smaller sections rather then throwing the kitchen sink at it all at once is it fair to ignore the obvious limitations and then complain about it.

Very few gameguru games created actually consider and plan their levels out carefully to take things like loading times into account. Just blaming the product isn't fair sure loading times could have been better.

However certain development choices were made that would increase performance overall at the expense of loading times.Considering all assets is loaded at the start instead of a dynamic system which might slow down performance. A dditionally incorrectly formatted or badly scripted scripts can often cause issues, some models are also known to slow down loading.

It isnt entirely fair to blame just the product there is still some human element which could have improved overall loading times equally.

Back to regards to the loading times of max games this is currently unknown as it is still currently in development, however considering the use of the 3rd party wicked engine, the realtime dynamic lighting system, 64bit engine, it is a pretty good bet that there will be a considerable improvement. Judging the product based on classic is bonkers as it is an entirely different product, while it still hold some marginal DNA traces of classic it isn't simply a reskin it is an entirely new GUI and completely new rendering engine, once it has been officially released the only thing it will have in common is the name and some ground up trace elements.

Since you have preordered I suggest you give it a spin you can download it from your product page and judge for your self, rather then judging based on a product that has nothing in common with the original ?

64bit vs 32bit engine has no bearing within the scope of what is actually the overall problem here well it is but kinda loosely and for other reasons. What really is the problem with classic is like already said the core fundamentals of the structure itself.

For example Loading all the assets when the game executable is run is a massive issue and tbh is majority of the problem with standalone and classic. 32bit engine only becomes an issue way after this fact and when one is trying to do advanced techniques or push above its ceiling. Also the fact that we as the end user are using lua against c++, dx and what ever else is going on this is the next big issue.

The editor feels snappy and running games via editor do as well. Its only when you go standalone the games loading sucks like 10-20mins for a game to load i have downloaded some of wolfs games, dk, RGB and others. So most of these people have tweaked their games as much as possible in terms of performance.

The only game i have tried so far with respectable load times is extraction point and that is probably due to mainly using stock assets/scripts. And the stock map big escape which again stock assets.

We are at the tech now where 32bit is not really a factor on performance other than limitations within the engine itself not the actual end environment eg the computer, we are way past any limitations on the computers.

Which then translates into bad performance because engine 32bit and ceiling in some areas on modern hardware.
But then on the other hand many 32bit games and applications whether old or new run very well on today's hardware, No 20 minutes waiting for the game to load that's for sure.

I stay at frame cap 100% of the time when working in the editor and running games from there for example Although i have not made any "big" levels yet mainly just a few entities and scripts so far.

Don't get me wrong I like the engine and really think that if they get this issue under control with max then it will be a well rounded great engine.

Atm its not viable for anything other than a learning tool classic that is.

Btw i am not hating here nor blaming anybody/thing just some constructive feedback because i like the product. If i didn't care then I wouldn't of bothered making the thread.

Nobody knows yet because they are still early in development. But if I had to guess I'd say the whole standalone process will be overhauled, with loading times drastically reduced.

Max is way under development (early alpha), so I doubt standalone side will be worked on yet as it's all the nuts and bolts put together. No-one knows what dev is working on what, it's going to be a long time before MAX gets any standalone attention.

Thanks for your replies all. Well hopefully they work out standalone on max because every thing else that is available is solid for the most part, easy to pick up and just create something and overall well rounded and intuitive.

opening up the loading process to user customisation would have been a good idea - let us add mini games or animated screens and the user won't notice the wait times so badly.

I agree GG's load times are a big issue, and while yes there is some human involvement there it's not entirely based on that. In my testing, even an empty level consisting of the starter flat plane of grass and literally nothing else can take around an entire minute to load from my speedy SSD. A populated level with stock assets can take 5-6 minutes or even longer. (For reference, when I'm playing Skyrim SE and exit a building into the open world, it loads in about 3-5 seconds. Fallout 4's worst-case scenario load times when exiting a building in downtown boston take no longer than 30 seconds, and with the load screen unlocker mod they take around 10 seconds.)

I really hope GG Max gets some serious improvement in this regard, as well as some kind of dynamic loading/unloading of assets since it's going to support much larger worlds of a higher graphical standard.

Really a minute.
Even my actual game does not take that long from desktop with intro added.
I think its less than 10 seconds from the actual menu.
Granted the levels not big but its there and not a blank one.

Load times vary. Here's my load times for level one of my Ewok game.

Not too bad, but not good if you have to keep reloading it every few minutes. As the game is more arcadey than normal GG games, that is entirely possible. The map here is fairly well populated, but is not anywhere near using all the map available.

Level loading times are a lot better than they were, but can still be considerable with certain media types. This is off an SSD as well, but not a particularly super fast one, Crucial MX500 rated at 6GB per second.

Yes it does and would improve loading times.32bit applications have a memory cap. In the case of classic that is very much applicable, which means a fair of data needs to be cached in the pagefile. With 64bit application most of it can be directly cached in the system ram, pending the size of the level and memory usage an entire level could be cached in the system ram.

Loading a level directly to system ram as appose to pagefile would improve loading time a fair bit. Considering the 64 bandwidth being an added bonus the overall caching should also be a lot faster as you will be handling and processing more data bits. Considering classic is quite heavy on gpu processing and a lot less on CPU processing. Even thought classic does have some multithreading capabilities it is mostly limited.

Max on the other hand with the implementation of the wicked the overall GPU/CPU balance is significantly better , considering the technologies used in classic versus max are worlds apart with regards to implementation of technologies. Especially with regard to the realtime dynamic lighting system, no shadow maps are calculated or loaded as it is done in realtime with cuts down loading time of any level quite a bit.

The bigger issue with level loading is physics collisions that needs to be calculated every time you load a level, technically speaking once these calculations have been done and cached it will be a lot faster.The more complex the overall shape of assets used the longer these physics calculations will take, having all your assets have polygon collision or more expensive collision physics when some objects don't really need it will result in longer loading times.

The human element does indeed play a particular role in long loading times. Why should an object on top of some the player can't reach have physics ? Why should a building in the background have physics enabled. Ultimately a big culprit is the end user not optimizing their assets placed.

A empty map with just a player marker takes about 10 seconds to load, and gameguru is installed on a HDD. Run the same map again and that is cut down to 4-5 seconds because physics have been calculated.

The coldwar pack, which is a complex level with lots and lots of collisions needing to take place, with the physics already calculated takes 64 seconds to load. That is actually pretty reasonable for this level, move just one or two objects in the level and the time goes up to 76 seconds, every time a object is moved in the level the physics needs to be calculated for that object again.

So having the correct physics collision for you entities is going to make or break your loading times, gameguru really isn't to blame in most instances. Imagine you have a 4 x 4 hollowed out block room, placing the player inside and calculating the physics for that room it will take an X amount of time. Have the floors walls and ceiling as separate entities, and calculate the physics.Which one would be faster, not the single entity as you need to have polygon collision on that, the separated parts just need simple box collision, which is a lot faster in the calculation needed for that.

The practical assumption it is easier to blame the software then the user, the user is never ever wrong, right ?

If Game Guru supported a wider variety of primitive collision shapes, we wouldn't have to rely on expensive polygonal collision so much. It's a chicken and egg thing; you can blame the user, but the software could make it easier, or teach users (let's not forget most GG users are novices and hobbyists) the importance of collision optimisation, and other forms of optimisation whilst they're at it.

For me, the most disconcerting thing about Game Guru's current loading screens is that the progress bar sits at 0% for so long before anything appears to happen. I know it's only a visual, but when nothing happens on screen for 10-30 seconds, you start to wonder if the game has frozen! Even if it froze at 30%, that would at least show something was happening.

AE

Game Guru allows you to sell your games but its not designed to be a commerically viable engine. There are caveats like the memory management resulting in relative instability and the loading times, lack of texture and media streaming as well as limited rendering capabilities. Now I doubt that this will change much with max, but since max is a 64 bit engine, its likely that at least loading times will improve. However, max will require a lot better hardware to run so that will be a whole new can of worms, as the amount of people that can run the games will be smaller than with GG max.

If you aim to sell your games from the get-go, I think its save to say that you are far better off looking elsewhere.

The bigger issue for me is the testing methodology used by lee. Almost certain when testing out the builds he has made, how often does he test the software to literal breaking point. Probably not often enough if at all.

@ wizard of id. Yeah i agree with you. Hence why i said "loosly".


Sure we can only address up to 4gb of system addressable memory on any application that is 32bit architecture because that is the limit. Running any 32 bit app on any 64 bit machine is automatically going to saturate most of this allocation to its full potential before we store cached information and then turn towards advanced kernel interfacing vs low level system management. Sorry my bad I was kinda half asleep when i wrote my initial comment because it was late here.

I guess what i was trying to relay overall for example though is that many software, games and applications that have been 32bit for years still ran very well even after the fact that we had moved to 64bit and beyond that further hyper threading. And because the fact that many standards take a long time to implement and for the industry as a whole to move towards the shift.
In GameGuru's case it would be because FPSC was made in the timeline where 32bit architecture was the more dominate platform and the latter was new and high end enthusiast level 64bit systems. So with each following engine FPSC is already the ground base work for the next engine.

32bit gives us a ceiling of 4gb but at the same time it seems that how this allocation is handled by game guru classic does not seem really as proficient as it could be.

Or it is just the fact that GameGuru classic has managed to squeeze all possible potential from its limitations and is already well above its projected possibilities/bounds of what is achievable hence time for max to happen.

I also understand that game technology, expectations and sheer scope of the climate has evolved pretty drastically over the last few decades and that there is many factors involved regarding game design vs hardware utilization. Even then GameGuru classic is several years old now and a lot has changed in that time. Its a hard discussion to have because of the many factors involved.

Also remember i am a noob with this engine and do not know everything there is to know about it and have only had the product for a week i can tell from your badge that you have been here since the start.

Agreed the loading bar and screens on some of the demanding GameGuru games make the application feel like its "hung" and needs to be terminated.

One example i can think that handles this problem well is a game like grand theft auto series and how it displays a slideshow of images so that the user knows visually that the application is still running.



I will admit here that i was taken off guard because as someone new looking from the outside towards GG and how it is marketed gives the impression that one can make it to that end goal of maybe selling a game. Which really is still a true claim just kinda a half truth in reality because lets stay realistic here. As i mentioned earlier some of your games and other ppl's games take over 20 minutes to load(Not literally sometimes, but just figuratively for "long load time" ) and that is not fun to any end user who buys any games made by classic. Not a knit-pick here just an observation i have read your blog and can tell you do a lot in your games regarding performance.

I am still open minded and like the engine a lot so i am happy to continue using it to learn and play around with to make games for myself.

Part of the furniture if you like.

Since you are new, and perhaps for the others that might need a refresher. Classic started out in the dark basic/weird visual basic hybrid tgc's own programming language, based on the old basic programming language but with the addition of 3D.So it isnt nearly as fast as you would get from C++. The code got converted to ms visual studio and then a rewrite of the core rendering engine and convention to dx11, eventually the legacy code was removed bit by bit and replaced with newer code. All of the code in classic is what TGC developed in house. You could call it a bit of ''Frankenstein'' engine, definitely much cleaner then it was initially, but still less then ideal, development costs and having released the product kinda put tgc between a rock and a hard place, either completely abandon the project and start fresh or improve and build on what you have.

Several others things happened as well, like the voting board for features that would improve the engine and nice to have features.That didn't go so well with most users picking nice to have features over things that would have improved performance and visuals.Gameguru had a kickstarter which failed and relied on private backers and a anonymous backer, which still wasn't 100% what was needed to get a strong software package.

What it basically boils down to is tgc had to make do with what it had, and it isn't bad at all, some pitfalls, and struggles, still a pretty impressive engine, it is no unity or unreal.It is targeted as a outdoor engine and does pretty great job in that regard with some limitations and such, it is a massive improvement of the previous fscp x10 and fpsc which was a indoor engine of sorts.Additionally tgc wanted to offer the ability to create various types of games like top down and 3rd person but that never really took off or developed well enough, kinda flew a bit close to the sun and got burned, it is just the way one laerns.

With max on the other and it is a completely different story, it is been develop from the ground up, no more Frankenstein code, or code conversion it is basically a clean slate.The rendering engine is called the wicked engine written and developed painstakingly by a 3rd party, project that exclusively focus on the rendering and engine aspects, no fancy GUI or stuff like that while it does have a editor, its primary goal is being a game engine.Tgc basically integrated it with their own GUI and code, or rather it is busy integrating it with their own code.

Rendering overall is much faster, more resource hungry but visually better some odds and ends that needs to be improved like close up shadows which has issues with the depth buffer.So honestly max has none of the old drawbacks of classic, bar its own issues but that is because of being a alpha product it hasnt been officially been released.

However releasing the product in alpha stage, having users test out the product allows for a longer development cycle before release, which in return makes for better testing and fixing issues for the first release.Max Can likely be in development for another 6 months before we might even get a glimpse of the first version, considering this product will be released on steam eventually, tgc is actively trying to avoid the backlash it got from doing early access on steam with classic.

So while it may seem like max is taking a long long time it is actually trying a different approach with getting the product shipshape and floating and navigating the waters before releasing the product officially.So a lot of experimenting is going on, there sole task for the past few months is the GUI and backend of that completely spit shined.

Not every one is enjoying the changes to the GUI and how the editor works, it is however expanding the usefulness of the editor with a bucket load of new features that most engines have had default for many moons.This different approach to the development is encouraging so far, frustrating in some instances with the GUI and editor is being wired differently to some extend and having worked with the creature comfort of the classic editor is some what upsetting to some users however they have added a few options now so you could reasonably tweak the GUI and how the editor works to your liking in some limited capacity.

They have their work cut out for them it will be several weeks before we have to starting worrying about how long it takes to load a game, but considering max has very little in common with classic other then some odd code here and there the engine is practically brand spanking new and has nothing to do with classic, and will run circles around classic.But most importantly the graphics don't look dated any more well sort of lol

Thanks for the backstory you touched on some areas i was wondering about. I have started going back in time today lol, Just to get an idea of the origins. Plus each day i am storing information about gg classic and as of today fpsc in my own personal repository. Storing free assets, links to guides and information etc.

I am mainly in the information stages atm and trying to learn as much as i can about this existing product and those that came before to help me understand what can and can't be done. Have not really looked into max at all yet because its early on and is the reason i started this thread. I have downloaded it but its still zipped lol.

Publish the novel.
"It is targeted as a outdoor engine and does pretty great job in that regard with some limitations and such"
Sure, I'm not going to argue there, except for what we already know; except for lighting and shadows
which outdoors still needs; multi-grass, and memory to enable all this -- the topic of our current discussion.
I'm actually glad GG classic was traded out for Wicked. I see this as the only efficient way for GG to
evolve into the higher tier engine-- just hope they keep plugging at it until it works.

"Game Guru allows you to sell your games but its not designed to be a commercially viable engine."
I think Wolf hit it on the head (or bit the neck if you will!)
But I think 88% of the users at least dream of having made a kind of successful ie >> commercially so
project. Therefore-- friction between the two behest the constraints. That's why I cringe at so much
accolades for high res PBR, and large poly objects all the while with a forward looking, FPS camera
that sweeps across the horizon-- and absorbs, then projects anything in view close enough at once
on screen (we still in Classic here).
But Wolf (and others) have actually proven that there's some capacity to accomplish some form of FPS
that does alright. (Not going into critiques) -- fabulous work from many members. Honestly genius work.
Still, personally, this is why I have basically removed the FPS genre from my ongoing GG thoughts, not to
mention I really am -- by nature -- no big friend of FP Shooters overall. And GG is at heart a FPS creator!
Ironic that it's the little 32 bit kid down the block that wants to play FPS PBR games with the big boys!
But I think GG Classic is at it's foundation a simpler genre creator ( I'm trying simplistic - yes try. )
I think top down/ Isometric / short frame or low-poly styles is where GG can succeed. Just need a little more
standalone help, as well as a couple other useful features. Let's see what MAX eventually becomes....

Well yes and no. It is slightly more complicated then a simple yes and no. But it can be done. Gameguru has a specific style geared toward old school shooters, these type of games still get made, so there is definitely a market for them.Gameguru graphics is about on par with that of half-life 2 ish graphics.It can do most of the things graphically that half-life can do, minus a few things where half-life fairs much better in.

Compare that to graphics of games now, it is definitely outshone by various tech improvements to lighting shading ect.It is not to say you can't create a similar graphics style to that of half-life 2 and still look good.Players are generally always first amazed by the graphics and technology employed scenery second, story 3rd and the overall interaction with the environment, the more engaging it is the better.

I have studied half-life 2 geometry, structural depth among others things quite religiously for future model pack ideas and styles, overall the geometry is pretty basic squares with some entities with structures modeled outside of the software with higher geometry detail. Half-life 2 heavily relies on the editor primitive creation for constructing levels mixed with decent external assets that is blended into the environment seamlessly.

Games today are slight less reliant on primitive creation, convex and concave polygons with primitive creation is still a thing with some game engines. So you would do pretty well constructing a similar environment in classic.The bigger issue most people can't model and is heavily reliant, free/dlc/ and store media, this media in general isn't exactly "game" friendly. It requires closed face polygons and reuse is generally considered top priority and should be usable for every possible angle.

This isnt very friendly towards creating large maps or a commercial game out of assets like that, not to say you can't, just there are limits and do cost a bit more on resources. With the exception of weapons characters, scripts, audio. terrain and grass textures and some entities,like barrels, lights, trees, plants, (the furniture parts of your library), you pretty much need to throw out your entire library with regards to buildings and such. And specifically model level specific optimized assets for the construction of your environment. In other words you only going to model and texture the part of asset that is going to be visible in your level to the player.

In other words if it is a a tall building and only two side of the build is going to be visible to the player you are only going to model those two faces of the building same applies to other assets that is static and is only going to visible from certain angle.Obviously you will need to plan your levels out before hand, adjust and make changes as needed on the fly. Generally smaller assets like barrels and such is model as normal. But with regards to structural assets or wall mounted assets that dont need back faces either texture them black grey or whatever or delete them entirely if it won't affect the requirement of walls and ceilings needing to be 5 units thick to avoid light maps leaking into the structures under certain conditions.

This would free up extra polygons and texture space a much needed resource, it is usually best practice with level designing in general, waste not want not. This is really just a quick example of needing change the habits and asset style you have become so accustom to, actually show just how wasteful standard assets are in general in gameguru.

So you would definitely need to change the approach on how gameguru is used, the bigger issue people needing to learn to model it isn't really what gameguru is about or who it is targeted at and that is where the no comes in, most people probably won't create a game that be sold with gameguru styled assets, it isn't impossible, just improbable.

If you change your aproach, work smart do lots of planning and map the game play, see no reason why you can't create decent game that can't be sold proudly, it won't be winning accolades or make millions of dollars, but it won't be accused of being another gameguru asset flip or if you have done your job a gameguru game.You will probably need to override constant urge wanting to jump off a cliff based on the obvious workarounds and problems you will encounter and frustration is going to be your new daily word of the day.

But sure with reasonable know how, determination and can do attitude I don't see why not, nothing is impossible, but like wolf said for most people probably not.

Good game btw @synchromesh this game you made was one of the games that initially sold me on buying the engine when i was looking at games on youtube.

Funnily enough i have yet to play it.

Also if anybody can chime in on the ebook? Is it worth the money? because its quite expensive in my currency. There is some areas and a few concepts that i am having trouble grasping and would like some in depth examples mainly modeling because I have never really made any assets before.

I have gathered a lot of reference material already but much of it is quite specific in some areas or already assumes that the person understands some of the concepts already. And many videos can be hard to follow sometimes because the creator might stray off topic or just because it is hard to relay much of the information in a reasonable time frame.

Im not sure it covers actual modelling as in creating them etc.

Yeah it looks more like coding and optimization based, but i seen it is over 400 pages long so it must be good. Kinda expensive and i don't have money to waste atm if it is not worth it. Been there before haha.

I am at the very basics atm with assets, like seamless dds textures basic and just now i am trying to learn blender followed the gg official guide on importing into the engine. Now i am trying to learn how to import free models found online which is hard because i don't know enough about it yet and the models are always set up for those that understand how to work with them.

Importing models ( static at least ) is the easy bit. its all pretty automatic and Manually doing it is just as easy.
Its making models thats harder and the ebook wont help there unfortunately.

I am grasping static items somewhat all though all i have really done is imported some cubes into the game lol. When trying to import something dynamic like a weapon found online is the hard part and i guess flies straight over the top atm, small steps.

Not that i have put much time into this area but i guess learning to retexture an existing asset is probably a good starting point but as a newb it is hard to know where to start.

I use Blender for all my occasional custom modelling needs. It's a lot easier these days to get into from scratch; although it will take some time before you can make anything half decent. Practise makes perfect. Start off with a cube. Work out how to texture it. Extrude some stuff; add some extra geometry and texture that. Watch some tuts.

Having appropriate media is a big thing in any engine. Game Guru being less powerful than most is especially sensitive to media. You can get great gains in performance with the right media. Low poly single texture objects that are simple for the physics engine are best. If you can combine similar objects, even better. Being able to make objects for your game is a definite plus! It gives you way more control over the poly count and draw calls in your level. This is why some creators make more impressive stuff

Don't worry about more advanced stuff like weapons. There's plenty about in DLC's and the Store. Concentrate on your scenery; the stuff you need to make your game, your game

You can make a decent game in GG. It isn't as easy as many would like. But it is possible I've said for years that the GG library could do with a complete overhaul. There's some janky objects mixed in there Some have been updated; thanks to users from the GG community. But I reckon many are still as bad as ever. If all these minor (and many are minor) object issues were sorted for default and DLC objects, GG would look a lot better out the box.

When learning how to use GG and wanting something looking nice, it's worth spending on some store or DLC assets. I like to do everything myself, but realise it's madness these days. If you can purchase media that fits for your game then do it! If your totally brassic, then there's some reasonable free stuff about, but realise it will likely not be optimised and could be way OTT polycount and texture wise.

I made plenty of mistakes when I started out modeling that did more harm then good, there is quite a bit more styles then shape modeling.Block out modeling works well in-conjunction with shape modeling and then there are other techniques like drawing and converting to mesh, things like rotoscoping is useful as well.

Overall you need to pick a style(s) or combination of it that works best, as you will at one point or another make use of all techniques all at once or a few at a time you need to practice the basics like beveling, boolean operations, polygon extraction, merging of faces, edges and points. The there are things like polygon deformations, duplicating polygons via a curve or an axiz.

You need to learn what each function does and how it may be applicable to your model, as you won't be able to create decent shapes without these additional operations at you disposal. Tutorials takes you step by step about how create a coffee mug, but none really explain why it is being done this way or what other uses these functions have that they use when creating their tutorial models.

Learning what these additional functions do beforehand is quite useful going into tutorials as it makes following them much easier and you can do a lot of shortcuts as a result of learning some of the functions that is intended to make life easier as well as making more natural shapes.



Take this image for example if you want to model this.Which is a relatively straight forward modeling experience, it uses several functions previously mentioned, and you will be making use of them.Once you decided what you want to model get as many reference pictures as you can of the item you are planning to model top/left/right/side, quite often you can't get bottom view as well it is quite rare. So often you can search for the specific part, if you know the name in this case I would like to see the bottom view of the engine block.Often you may need to find a completely different brand or image that gives you some idea of what it looks like. If you don't know often you just free hand it and guess what looks good, the last part comes naturally eventually.

Second part is studying the shape(s) contained within the model mostly squares and cylinders. This is where block out modeling comes in extremely handy tool, it helps visualizing the different shapes needed in the construction of the model. In the case of this model there is quite a bit of guess work as not every thing is visible even with all angles available. Like the fuel tank on top. The output panel on the side little odds and ends that you will need to model by your own design, even forgo completely.

Dvader mentioned low polygon model, well not entire true, you don't have to start out with low polygon. You actually want to model reasonably high polygon, with lots of detail, used for creating normal maps and bake details into a low polygon model. Considering you won't have actual textures for this model and will have to make use of tools to paint textures like substance painter, or quixel. Generally I use a different approach where by I paint normal details into the model. While I may use a high polygon model, I make use of polygon reduction afterwards, it is a function that reduces the amount of polygons on a model or part of the model. In this case the cylindrical frame that the engine sits in. It requires several functions to create.You will have to create a cylinder primitive and use a function like extrude via curve. The curve is some thing that you have draw in the shape of frame holding the engine.Benefit of using a function like this is that the polygons is attached to the curve so that you can manual edit and move points around the curve to better shape the frame as you need it to be. After freezing the function, when you are happy with the shape you can use polygon reduction that will get rid of unneeded edges on the shape you just created while still retaining the original shape or close to it.So you don't necessarily start out with a low polygon model and generally better to use more polygons at the start which can be reduced later on. You do want to get as close to the shape of the thing you want to model, if in doubt use more you can always reduce afterwards.

I probably over complicated things with this explanation, but the idea is to train your mind to look at what you want to model and mentally get an image of what shapes it contains and how you will use the tools within the software to create said shape. Once you actually start seeing the shapes contained with in the object you want to create it take a few seconds and you can easily blockout the general shape of the model from the shapes seen in image or object you want to model.

Essentially if you are going to learn to model you will need to learn the tool you will be using and the most important functions found in the tool you will be using most often. There is some functions in my tool I will never use, so if you can learn the important ones it will make life much easier when modeling as well following, tutorials. I never watched tutorials as it never really helped other then making me even more confused as i most often didn't understand what they were doing and often just gave up.

So I had a messy experience and delayed any progress I could have made with a solid foundation and understanding of what I was modeling.Best advise I could give is learn the software and learn what functions it has, before attempting to model any thing whether a simple barrel or box, do the basics over and over and over. See what the beveling does or extruding of edges, points and faces.

It is basically like learning how to draw but in 3D and drawing on paper it also uses primitive shapes, circles, squares and triangles as a starting point when learning, but as you become more accustom to the shape you drawing you become slightly less reliant on them but still helps if you needs to get right perspective and scale.

Once you have done it many times, it becomes second nature and fun, just practice on the modeling part, texturing and uvmapping is a skill and art form on its own and will take many more weeks to understand and practice on it's own.It is daunting task, and tutorials expect you have some prior knowledge, so watching a tutorial on creating a character isn't going to help it requires that you know the basics and have a foundation, so don't bother with them, start out with tutorials teaching you about the software and the functions it has and how to use them, once you have done that every else will fall into place.


Here is and example of a model I made using the blockout method, this is also the first ever vehicle I decided on making, it's not perfect, but looks decent enough.

Absolutely true. Low Poly isn't just an "easy way to model", it's actually quite hard, and an art form in itself, and most of the time you have to be able to model the object in High Poly first t be able to understand how to make it Low Poly.

HOWEVER, just remember when someone says Low Poly, they might be thinking of something completely different to you. There are many forms of Low Poly modelling, but there are two distinct categories that stand out ...

Low Poly style and Low Poly geometry (names i made up but fit well enough),

- Low Poly style: With Low Poly style you are creating a model that intentionally looks Low Poly, for example any of the Synty Studios Polygon models, however the underlying geometry doesn't necessarily have to be low poly, i've seen low ply styled models have some really high poly counts in the past.
- Low Poly geometry: With low poly geometry you are trying to create a model using as little geometry as possible but retaining as much detal as possible, this is usually achieved as WoI said by creating a high polygon model and baking the normal and height information onto a low poly version of the model, or by manually painting those details in a texturing program.

As you can see, they're both very different styles, but they both require the same level knowledge of the subject to achieve, and it's not just technical details about the software you're using, knowing the subject you are modelling really helps too, for example modelling a character requires you to understand the overall shape and proportions of a body, even for a stylized or low poly style character if you get the proportions wrong it can make it look bad, generally you start with correct proportions and then adjust and exaggerate them to get the final look.

So, yeah as WoI stated, i would recommend learning the ins and outs of the tool first, get used to what is available in your tool and practice using each tool, then when you move on to modelling, try to make detailed models, don't worry about poly count, this will just be practice, and when you are familiar with your subject, then start formulating workflows to reduce it down to game ready levels. But most of all practice, don't be afraid to repeat the same object over and over again until you are sick of it, starting with basic shapes, there's a reason almost all art classes at some point get you to paint a bowl of fruit and a wine bottle over and over again, it's all about the primitive shapes.

@ Tresgamer
I Love some blue song that says something like "everybody tries too high" maybe starting by the basic might the best. Putting the bar too high may end up frustrating yourself. Make a model just to learn to model, and no to make a game, this will come later.
The learning curve is like a stair, just start by the first step.

Actually forgot to mention so thing with regards to max, and is applicable higher poly models is preferred with max in certain instances. This is to do with transparency parts on a model, rendering will be slower with rendering a grate model for example then modeling a grate without transparency lee confirmed this for me with the realtime lighting.

Of course there is certain instances where this isn't possible like a chain link fence for example. So levels and assets should be balanced with regards to use of assets with transparency parts. Not all assets requires shadows so you could turn it off for some models.

Just thought some thing interesting and worth mentioning.

So let me get this straight, what you're saying is that Max performs better rendering geometry than it does applying transparency through a texture right?

That makes sense to be honest, from what i'm reading all over the place, most modern engines are now more efficient displaying geometry than they are at rendering textures, and transparency in textures is a biggy it can double or even treble the size of a texture file. But yeah as you say it's a balancing act.

Remember it is not baked shadows but realtime and dynamic, and will kill FPS quite quickly. It doesn't preform "worse" per say, but calculating the shadows is going to cost you performance in the long run if you use lots of them.

Apart from having normal draw calls we also have shadow draw calls as well now. Just some thing to keep in mind. Additionally I have already shown, with some example stuff, max can render a 50K polygon model pretty easily and quite a few of them no issue, placed 100 and 200 of the same objects for a total of 5 million and 10 million polygons on screen without issue, FPS was lower of course, have a pretty weak GPU but it was just about playable.

So you better off using slightly high polygon count then transparency additionally gameguru has some default shadow resolution size and distance values, which is actually pretty average values if you increase those values and resolution with lots of transparency in a scene it is probably going to tank the FPS a fair bit lol, I can't remember if they are at the lowest or med values. It is a pity you can't select individual asset shadow resolutions it would help a lot, instead of having standardized shadow resolution for the entire map.

Notice how the FPS basically halves, So yeah shadow rendering is going to cost you big time, also notice how the shadow draw calls doubled.

Medium shadows


High shadow and distance

Snap! The only problem is, I'm not a professional modeller. As ever in game dev, I will need a specific model, It's not readily available on the store, so I attempt to make it. Done and dusted, down to the time it takes, which can be considerable. One year later, I need to make another, I've definitely forgotten the fine details by this point and end up going through similar issues, although I remember more each time Although when the package you use suddenly changes massively, it doesn't help at all.

I wasn't trying to give a full tutorial, just some pointers to get started. There's obviously way more to modelling than extruding faces from a cube. I am for certain nowhere as well versed in 3D modelling as you are.

Also, when I mention low poly modelling. I am just so used to performance issues, I always make my models as low poly as possible. Not in a low poly style as suggested, but just as low as I can get away with for it to look correct and tolerable

But back to loading speeds mentioned (my low poly models being better for that lol) GG is for certain slow, but you can speed things up with some media tweaking. Different sized textures for shader work. You don't need your normal/specular/illumination maps to be the same size as your diffuse ones. Same for PBR stuff, but I have not delved into that much yet.

You can speed things up by making GG keep models loaded in a prior level and not having to load them a second time. Although I am not sure how reliable that is as yet. By all accounts the next update should be a lot better in that regard.

There's a lot you can do to improve loading times. If you are willing to do the work. If you just want to load ready made objects, plonk em down and be done, you will not get the best results. As much as everyone wants it to be the case GG for certain has some janky media that causes both in-game slowdown and potential loading speed problems at the same time. Use well optimised media and you will see a big difference across the board.

That said, GG will never be a beast at loading up. You can do what you can, no more. Unless Max has some update that ties in with GG that speeds things up, then apart from good model creation/selection and texture reduction, there's not a lot else we can do. Reduce anything that has to load as much as possible. You will get improvements But it is work.

You may not be aware but the impact of using higher polygons is negligible at best of course with in reason. It doesn't take up a lot of resources, like texture would for example.

It is better for example if making a building to have it as a single entity instead of parts to make up the final building.You do this to reduce draw calls, the less you have the better the overall performance is going to be with classic, max is slightly different. I have already maxed out the draw calls in max which would have been pretty bad in classic and ran decent enough in max.However max has a new public enemy number 1 which is shadow resolution and shadow distance as mentioned, this increases the shadow draw calls and at the moment is a frame killer.

With max you can let loose a little on the texture and polygon front, of course within reason. The system handling these things are far more optimized and better, with the addition of 64bit computing and better threaded support. I suspect you could do 10 times more in max then what would have been possible in classic.