Howdy!

Open world video games, from fun sandboxes with many possibilities, over tightly structured quest lines that can be tackled numerous ways to hollow empty wastelands with occasional activity hot spots. A genre that has gained more and more popularity as media streaming and hardware have drastically improved from what we had in the 32 bit era. (Regardless of this, the Elder scrolls series like Daggerfall, Morrowind, Oblivion and Skyrim have all been 32 bit games. More on that later.)

Now, its not hard to guess how so many GG users have gotten inspired to try the open world route, and given the fact that GG is entry level technology, its easy to understand why so many people jump right into a project without testing wether the engine can do what they want it to as they have no idea how a game engine works in general.

I'm writing this because I find a lot of GG users try to make something open world, usually a zombie apocalypse or something inspired by Behtesdas Fallout games... something generic down those lines, which will inevitably fail (or end up a 10 FPS slog with some zombies scattered around a horrendous level, which is also a failure). In fact, 3 users have already hit me up working on something that was supposed to be a dynamic open world game and one of them even made substantial strides and was now of course suffering performance and stability issues. You also find several projects like this on YT or Game Jolt if you go looking for them.

So, I will take a couple minutes to explain why open world projects are not practical in game guru and what you can do if your game idea absolutely has to have some sort of non-linear design or similar.

1. The default size of buildable space in a game guru map is 1298*1298 meters (alternatively I have heard 768*768 but I asked someone to run a script and it gave a larger number). While that can make for a nice spacious level, it does not make for an entire game world. Even if you plan on something smaller, you can not use the entire
space of that level without running into heaps of problem. So using half of that space and reserving the rest for background decor works best. So you might say, okay, then I break up my world into several levels that the player can travel to and from:

2. No! Every level load in GG is a bit of a gamble when it comes to stability. Will it crash? Even if it doesn't, most world-values, by that I mean permanent scripts like inventory items, the players cash and so on will not carry over from level to level. Here you will run into a brick wall as far as most open world survial designs are concerned. Then you have the memory issues that pile on and make a level increasingly less likely to load all its media the more often you load a level. Adding "allowfragmentation = 2" supposedly aleviates the issue but it does not fix that. Add to that, that, I can be wrong on this part but I am pretty sure its true. There can only be one player start position per level making traveling back and forth not align thematically. Also note that all enemies killed before will naturally be there once you travel back.

3. Open world implies that all your functionality is in the same level. While you can spawn enemies to improve performance you will end up running a lot of scripts in a level that is probably full of models already. Having this many things run in tandem with each other will likely crash...if by some miracle it doesn't, it will lag.

4. The good old memory cap makes large levels impractical and unstable.

5. Game Guru loads in all its content at once. That makes for longer loading times, the larger your level is, the larger your level is, the more can cause a runtime error and the more likely will it lag. Open world games like morrowind or skyrim where 32 bit games when they came out, so they had less address space themselves, how did they do that? Loading in cells and unloading them on the fly. GG can not do any of this, no content streaming, no nothing. A level loads in all media and there it is.

Now here are some things you can do, that are practical :

1. Focus your game to have a maximum of 15 levels. I know that, if you are a beginner, that this might seem to be way too small to fit in your epic idea but just go ahead and make a couple playable levels, find out how long it really takes to make a game, even in Game Guru (unless you just use pre-made assets, then it goes fast). The reason I say this is because you can somewhat realistically fit a working game in 15 levels if you play your card rights. A more cynical and probably more realistic estimate would be 6 levels but lets be optimistic here.
2. If the player has to return to the same village, outpost, castle or whatever throughout your story: You can simply manually copy and paste your level, and then edit the level according to what has to happen in the story. This will then be a whole new level but it looks like returning to the same place for the player. It would look something like this in your level load order:

Level 1: Hub World Castle
Level 2: Spider Dungeon Quest
Level 3: Hub World Castle 2

3. It is possible that loading in a smaller level from time to time, without lightmapping, might free RAM space more efficiently (?) so having a small Hub world would be beneficial.

4. Design your game to follow these principals:
Number 1: Linearity isn't always bad, even though some youtube game critics think it is (the best shooters so far where all linear).
Number 2: Make a few notes of what has to happen during a level so you can make sure that not too many dynamic scripts operate at once.
Number 3: The ideal level size is half the default buildable space or lower (especially lower). You can use the remaining space for background decor like billboard trees, lowpoly houses or what not.
Number 4: Make prototypes and test! If your game is supposed to have dialogues to convey some kinda story, prototype that before you make the levels so you know wether your features can even be implemented or not.
Number 5: Try to design a game that does not need an inventory to carry from level to level.

And here it is, I hope this is useful to someone out there. If I can make at least one person not sink countless hours into an idea, inspired by current gen games, only to end up staring at a run time error, this served its purpose.

Additional Comment by T-Bone:

I'm glad this topic was brought up and I think it should also be carried over to Steam. A lot of people have high expectations that they can make the next Fallout or Skyrim in GG Classic. Its simply not possible. Defy did a pretty good series of memory tests and found a lot of limitations in this area (hope we hear back from him again soon).

Unlike GG Max, GG Classic doesn't have a terrain neighboring system (similar to cells). If you are planning to make a large outdoor level, you will have to consider reusing instances of a few entities for rocks and trees. You will encounter memory issues over time if you expand too much with too many unique objects - while also running other media into memory such as sound and image sprites.

It should be noted that using entities with LODs actually uses more memory than an entity without LOD stage meshes. These types of models are for maintaining stable FPS performance. Also if you are doing an outdoor level, you may have to consider not using PBR models as well, as those models use a lot more textures than the typical DNS.

I would highly recommend creating linear games with Classic, using memory clearing between levels. Similar to a lot of the PS1 and PS2 game era. There's even a lot of games back then that do not carry over any values between levels.

Nice one Wolf, hopefully, many people will take your words as a guide, before starting the exciting adventure of designing a video game.
It is always important to know how to create a video game and not die trying.

Thanks for this informational edict Wolf. A good template to keep in mind.
15 levels?! I think personally I'd also stick with the 6 idea. It was about 5 or 6
on my first project that indeed I did jump right in, gung- smack- ho!!
8-9 FPS, missing a few things- you are on track with that. Even had story zones
and other trigger zones that got mixed up somehow? I don't think they had the
clear memory option 2 years ago- or I certainly didn't know about it.

Some of the player positioning questions could maybe be overcome
by some creative scripting? But thoughtful- spot on tips.

Very good advice Wolf, I have always felt that FPSC and GG both feel more like a mod for a game than a proper programming language. The fact you cannot load any model in on the fly is testament to that. At least we can load images and sounds now via scripts. Not being able to load or delete stuff in code for certain limits what is possible.

For certain player start position can be changed, I think I actually did something years ago along those lines. It's not something the average user could do though and needs a bit of scripting know how.

GG is for certain more aimed at simple shooters with a more linear design than open world games.

This is the part that gets me about GameGuru:



THAT should be a basic that is included. It's not really a level load if it doesn't carry over vital information, such as inventory items.

Excellent post! /.-)
It will surely help those mentioned in the introduction...

However, here´s some personal thinking on the idea of "open world".

What Game Guru and Max are in need of and would be NOT so difficult to realise in it´s code -based funcionality is the following:

AN ENDLESSLY WORLD / SCENE / SCENARION

Remember those 80ies times with no memory whatsoon for even decent level-design? Welcome to the infamous idea of making the player reaapear on th eleft side of the screen, when he leaves it right of the screen.

I`d put it simple: I would LOVE to have th epossibility to blend the edges of "my universe" seamlessly into each other. As very far objects do not to be rendered, it would not hog the computer. Maybe the matrix needs to be no too small, tpo avoid any crazy optical feedback illusions, but why the heck no?

I had this idea of doing a 3D-WUMPUS.

/.-)

Yeah, would make for an honest disclaimer.
Maybe put a 'must read before purchase' link to this post next to the 'buy GG Classic or GG MAX button'.

Might lessen the downer people will feel after purchase.

I would like to analyze this "carry over from level to level" via inventory.
When someone lists some stuff in their inventory system, let's say in a level1, don't miss something important here, that stuff already exists over their map, that stuff physically exists there, but they do not exist in the level2, physically that stuff is not placed over their map in the level2; so he is referencing in their inventory something than does not exist, this behavior most likely thrown missing media error.

So, is in this stage where GG engine has to virtually place inventory stuff over their level2, notice I'm talking about the virtual way, that means when the player wants to use a medical pack he brought from level1, although that pack is not placed physically by the user over their map in the level2.
Here there is not enough with scripting, it needs the engine prepared to do so.
GG relies most on the stuff over the map at a specific level and does no matter what's the inventory say.

Nothing actually exists on any level, it's all just numbers in memory.

I meant user placing physically meshes over the map, and yes, GG storing data in memory. (for this reason, I remarked "virtually")

It doesn't matter whether it physically exists in the level or not, user-made global aren't stored from one level to the next. Say you have to collect some coins. There's 6 coins to be found, but it does not matter how many the player finds for their overall progress. You write a script that starts with a global called 'coinscollected', which in level 1 is 0, but as the player collects coins, the count goes up. At the end of level 1, the player has collected 4 coins, coinscollected = 4. You load level 2, there are more coins to collect. The trouble is, Game Guru doesn't store the value of coinscollected from level 1 into level 2, so as far as it's concerned, coinscollected now = 0 again. AFAIK, the only way to get around this is to write the value of coinscollected to a file outside of Game Guru using the fileIO commands in LUA. This is beyond the skill level of most Game Guru users.

Theoretically, you could construct a inventory that worked level to level, but it would have to store the values of everything in an external file. Depending on the complexity of the inventory (and let's face it, most RPGs have loads of items and sometimes items which can be upgraded and/or changed), the LUA would get very complicated. Yes, it's possible, but it's in no way for everyone.

AE

That depends on how you code the inventory system, most use variables and tables, so you just need to design a way to carry that information over but the one that smallg made a while back relies on actually having the physical object and it's associated ID on the level so can't be populated between levels except by having the entities present on the second level.

@ Avenging Eagle
I know what you are talking about

I've already written my own inventory times ago, there may be some vids somewhere, and it works fine but relying on an external plane file storing the data for later use; anyway, as Belidos points above globals vars are not updated between levels, we need the GG engine collaboration with this matter.
In my inventory, I take into account when user run out of room (inventory full), so I've coded some safe bank to store items there and get free room.

Inventories are not complicated. I was doing that sort of thing when I was 12 in Spectrum Basic. Text Adventures were about as good as you could get with that really and all had an inventory system.

GG is great to use, but can be difficult to add more complex (or custom) stuff in. This isn't always because it's hard to do, it's because you end up fighting with GG for control of stuff.

The more "automatic" stuff put in, the slower and more bloaty GG will be. We already have the issue that lot's of stuff included in standalones aren't needed at all. Lets not encourage more of it.

AE already has a script that carries data over between levels by storing/loading from file, I know cos I wrote it.

The same script could be expanded to carry over anything you want to, they are just numbers after all.

The only things that would have to be placed on every map would be the player weapons.

I'm glad this topic was brought up and I think it should also be carried over to Steam. A lot of people have high expectations that they can make the next Fallout or Skyrim in GG Classic. Its simply not possible. Defy did a pretty good series of memory tests and found a lot of limitations in this area (hope we hear back from him again soon).

Unlike GG Max, GG Classic doesn't have a terrain neighboring system (similar to cells). If you are planning to make a large outdoor level, you will have to consider reusing instances of a few entities for rocks and trees. You will encounter memory issues over time if you expand too much with too many unique objects - while also running other media into memory such as sound and image sprites.

It should be noted that using entities with LODs actually uses more memory than an entity without LOD stage meshes. These types of models are for maintaining stable FPS performance. Also if you are doing an outdoor level, you may have to consider not using PBR models as well, as those models use a lot more textures than the typical DNS.

I would highly recommend creating linear games with Classic, using memory clearing between levels. Similar to a lot of the PS1 and PS2 game era. There's even a lot of games back then that do not carry over any values between levels.

I use saving and loading of variables between levels and during playing a single level, but you do have to write all the lua code for entity states, doors opened or closed, events triggered, a lot of work, but it can be done. I hope MAX will be a little more user friendly and maybe have some sort of save load system incorporated into it. As MAX is using a new engine maybe that would be possible.

I think the same.
I accept and also know it because I have already done it and it works, that an inventory can be created via LUA.
Anyway, I think that gameguru / Max regardless of the inventory, should keep the values of the global variables between levels, whether this is possible via LUA code, or not. imho.

I don't deny that it can be done in theory, but my experience with people's alphas that had this feature where disastrous.
Even when the inventory and cash system worked for me, it gave another tester a run time error which some time a coder has to explain to me. Then systems that should carry over data, did sometimes, not other times and with the cash system, it would carry over a random number different from the cash collected in the previous level. So while this particular obstacle can be beaten, its not practical considering the scale of an open world type inventory. For a shorter, linear experience... sure, if done well.

@Tbone: I added your post to the main post of this thread, thanks for the insight!

If you need to get items out of the inventory, rather than just use them, yes. You would in any other engine as well, the difference being you have that sort of control with them, whereas in GG we don't.
I've said it before and will probably again, GG is more like a game mod than a proper game dev engine. ANY other engine/language I have used, bar FPSC (another mod affair) allows you to load media and remove at any point, this is where GG really loses out to all other engines. Why you can't do cool random generation stuff and why things don't carry across from level to level well.

Also @3com. Are you saying variables with a g_ prefix do not work from level to level? That is the entire point of globals! I'm sure they used to work fine, but perhaps not?

Edit - Just tried making a couple of basic maps to load between and for some reason, the winzone does not even work at the moment. I then loaded up an old map I had already made for similar tests and that worked fine!

The above map I just made and doesn't work. I noticed the winz zone being a box now which was odd. Does not work.

This one I made ages ago and works fine still. The Zone is now the (for me) familiar house shape.

I'm wondering what has caused this and can understand why people can have issues when I can get two different results on the same machine!


@Wolf. Sounds like the script to remember cash values was not working properly, rather than a specific GG issue there. But hey, when you see the two examples above anything may be possible!

I don't usually do it, but I have created a simple standalone file with only 2 levels and with the sole purpose of testing its operation.
It is about collecting 5 keys throughout the game in order to open a door, yes, something very classic but useful in this case.

I use the collect_towin script with some modifications.
A global variable called g_collecting = 0 counts all the keys found, when the player finds all the keys the global variable g_openDoor = 0 becomes g_openDoor = 1 and the door opens, otherwise, it gives a warning such as an image below, and yes, sorry for the error in the sentence, I saw it in the video.



The image shows that GG does not take into account the first 2 keys found in level 1, and only takes into account the keys found in level 2, therefore the door does not open as expected.

Conclusion: GG does not update/keep the value of the global between levels: And yes, I know that all this can be achieved based on scripts, but not thanks to the correct operation of the game engine.
Also, I have an invisible wooden table, and this table is a stock item.

I believe that what can be achieved with the fpp file can also be achieved with the text file called contents.txt, although I have not tried it yet.

Although I believe that the failure of the standalone file in GG is a necessary evil, it is a tactic that prevents the market from being filled with junk games made with GG, and its subsequent consequences for GG's credibility as a game engine.

In case someone wants to create controversy, I must make it clear that I am not justifying or criticizing this behavior, I just limit myself to expressing my ideas about it.

@Dvader if I remember right the g_ prefix wasn't added for carrying over levels (although it does albeit a bit randomly), it was added to allow variables to be saved with the save game.

yes it can be done by writing to a file etc but it's not really simple though, you need to consider what happens if the player starts a new game or loads an earlier save file and even worse if you allow for multiple accounts/users in your game... meaning each file must be linked to a user and a particular save. (this is true for any game engine though)
however GG makes it even harder by requiring items be in the map to be used (i.e. to add a weapon, ammo or health you need the specific entity so the stock commands actually work) as you can't simply load these by script and there's not really an easy way to cheat and while you can do it by script only the values would be more hard coded to the script (and last time i looked the manual adding of pool ammo didn't actually work correctly)... it's certainly not user-friendly and suffers more from its early "simple" methods than it needs to... GG really needs to add spawning of new items by script to really open this sort of thing up.

I keep alluding to Lee that script spawning of entities is a very valuable
feature, and Lee keeps agreeing- "Great idea. Add that to Github so we
can look at it." Hopefully MAX could have this, and if so, would Classic
inherit it just as easily or no?
Yeah, maybe at the proper time so it doesn't get buried into the landfill
of forgotten requests- someone will add it @ Github.

@Belidos. Ah I imagined as it was a saving system, it would save them at level changes as well, perhaps not. If it doesn't carry across levels then it's not massively useful.

@gubbyblips. He's been agreeing since 2014, lol. We will never see the ability to load items into GG directly it just doesn't work like that If it was easy to add Lee would have added it. We can spawn enemies though, just only ones already plonked in the map not new ones from lua code.

Max on the other hand should be a fresh start at it (sort of), but if it is the same in Max we will be in for more disappointment as far as these types of game mechanics go. If we have to load in as many potential items as will be used at once then we will always have to have every item we need loaded from the start.

@Smallg. The issue with GG is we have too much stuff done automatically. It would be a way better idea if we had easy access to switching stuff off and doing our own thing. Most of the things I have been attempting of late have been hampered more by the automatic stuff than anything else. I also hate if you DO go into the provided code to alter or change stuff you are messing up EVERY other game that uses it. So you have to start having back ups of standard GG code. Then it updates without you realising and wipes your changes... Nope hate the current system with a passion.

GG could allow cloning entities via script just as it does via the F9 key.

@3com. There must be some caveat that has stopped Lee from adding it. I've asked for it many times and so have many others. If it is already in and easy to add I would imagine he would have added it to simply stop the requests lol.

Much agreed @ DVader. The auto automation has seemed to "step on the toes"
of actual freedom to expand the GG engine.
But there are some things that must be done through the engine @Lee as they
are just not possible in scripting. Instancing models by script for example.

It really would be a pretty immense benefit.
@Lee; you have pet Zombies lurking in the basement, but come out into the
sun and let the players build the castle to protect us from the Zombies!

There are a whole host of reasons he hasn't added it, just one as an example is that GG precomputes the position of entity collision shapes so that AI can navigate the level, if you spawned entities on the fly not only would the game have to stall whilst the mesh and textures are loaded but the collision map would need to be recomputed to take into account the new entities. Suddenly adding an entity where other entities already exist would also cause havoc with physics, existing AI that are already navigating that space and any Lua scripts that rely on knowing where entities are.

It could in theory be implemented in Max without one other issue rearing it's ugly head and that is light mapping, GG needs all the entities to be present in order to light map the level properly, suddenly sticking a new entity into a light mapped level would cause it to stand out like a sore thumb.

Precisely one of the concerns I have with one of my games. Lots of consideration for when working on the read/write process. Lot of games allow you to have different instances/slots of your playthrough with 1 account.

I think for GG I have to really really simplify things to get this working properly. Limit one playthrough to have only 1 slot. Though if you make a mistake and save a bad playthrough position, your screwed. So for this I'm making permadeath an option and something I'd hope most of the players choose. This way there is no saves to go back to, only 1 to proceed forward with between levels to store items. If you die you lose all items and progress.

Re dynamically adding (and deleting) entities. Apart from the AI obstacle and light mapping issues Amen raises it is reasonably straight forward to add to the engine.

Cogwheel used it to generate collectables on the fly and add random procedural trees and small rocks on dynamically loaded terrain.

Cheers.

Hmmmm...? Maybe stock AI is never added to some peoples levels! Are we
still in Zombie Level Creator?
These specifics sound to me to be related to more auto generated parameters
that MOST other engines will not entail; "so that AI can navigate the level" /
"cause havoc with physics" / "scripts that rely on knowing where entities are." /
"light map the level properly,"

Leave it to the developer to manage their levels. GG could enact a manual
mode to the level for people who wish to freely develop their levels without
these (seemingly archaic) and GG specific constraints. Is this a Bullet Engine
problem?
Sounds simple- won't a new object still cast a shadow, have collision and X,Y,Z
coordinates?
I would like to see an attempt at it, and when it has been proven that it's not
nearly possible- then we give up.

For Max we will probably lose the light mapping anyhow and if the user is knowledgeable enough to be able to avoid the physics issues then yes it could be done with a bit of a redesign of the way GG works under the hood, but it is already fiendishly difficult to design a decent game with static entities, who here will put there hands up and claim to be knowledgeable enough to do it with ones flitting into and out of existence on the fly? (apart from me and cybernescence of course )

Personally I simply re-use the ones on the map already if I find the need to do that sort of thing, like have a couple of *real* health packs off in some corner of the map and place them where I want in real time as the player wanders around. When they are collected they simply get repositioned somewhere else. Using this mechanic you can have endless health packs (or weapons/food/etc) in your game.

Gets a bit more complicated if you do the same with trees or buildings for example, you will find that AI get stuck trying to negotiate the map if you try it.

Me. At least in any normal programming language. I wouldn't try to load stuff on the fly as such, I know that is slow, but having a way to load up stuff when I chose to would be great. I'm only an amateur but I've been one for a long time I remember having to double buffer stuff to get it smooth lol

Example: Pacman
Would be easy to make but you would have to manually make the maze. If you can load objects then that would be sorted way faster and be super flexible in code as then you could make hundreds of mazes far faster than you could manually. It could be done now, sure, but it would need you to load every possible maze chunk into the editor manually. Great until you realise you want 20 different maze styles. now you have to load all 20 maze styles in at the start. Having the ability to load what you want when you want is for me a basic option. Perhaps I am too spoilt by actual programming languages

I made a maze creation Lua script which simply works by hiding walls at run time, basically you create the default maze with all walls present and then have several alternate maze layouts with certain walls hidden which are applied at run time.

So the player could walk the first maze and reach the exit but when returning to the maze it has transformed to a different layout, I did that in GG probably around a week after downloading it for the first time, i.e. around 4 years ago!

So we are worse than I thought, if only 2 people in the world can do this, I suppose the rest of us will be the static entities that we can do nothing apart from observing.

There are workarounds Amen, but that doesn't change the fact if you wanted 20 different wall texture types, you would have to load em all in for a lua script to work. Having 100 different mazes that look exactly the same would be rather boring. Regardless of if the maze is a different layout. There's lot's of stuff we CAN do in GG, but I'm just pointing out the obvious stuff where having to place objects on a map is hardly ideal I'd certainly prefer an option to load new textures in and re-texture the objects for each maze in code rather than manually having to add em in Or of course just loading in new models already textured, whichever seems the best solution at the time

Basically from a coders perspective, I want to spawn as many objects as I want in code. I don't want to have to place down 1000 trees in advance so I can do a random forest! Then find I need 2000 to really get it looking nice, or worse finding I've plonked 2000 down and it crawls. Doing this in code is so much faster when it comes down to the crunch. I can test x amount of trees as many times as I want.

@3com
Well, if you actually believe that :0 Amen is perhaps exaggerating. It's actually the norm when you actually code something from scratch, although modern engines make a lot of stuff a lot simpler. Pretty sure SmallG would have no issues either, along with several others, but you may be just joking lol, hard to tell in comments Static objects are just a fancy term for objects with no extra code assigned Before I used FPSC or GG I just called them objects There is no spoon ;p


Some of us come from other programming backgrounds and know what can be done and what can't. We're not all Air Line Control programmers of course
The demo below is years old and shows AGK ( V1! ) can do some cool demo's with very little work. There's no way to do this in GG other than silly amounts of work to get the same result. Not an example of loading entities, but a good example of creating them on the fly.

A quick pic to show what to expect As I say a simple but effective demo.

@ DVader
Sorry mate, my preview comment has nothing to do with you; It is only then I believe fortunately we have good coders here that can do so, anyway if we have to be a first-level coder, what happens with easy game maker.

I was working with something similar to make a maze, but in my case, I did some Magic square game to play in GG, and I was thinking about writing a random numbers generator, and I wrote LUA script Siamese method based, to do so.

Let's be clear, I am only addressing the potential of MAX, and 32 bit Classic
has already had it's premiering days gone by.
"who here will put there hands up and claim to be knowledgeable enough to do it with ones flitting into and out of existence on the fly? (apart from me and cybernescence of course )"

Come-on! Is that a thoughtful question? If you are going to load an entity
you had better have a plan on what to do with that entity before loading
it in. Same with sounds. With sounds, you have a plan on where and how
to use them. You set their values and use them at the moment and setting
that the developer plans. There's plenty of great code you kindly created and
expanded Global with, AmenMoses that nobody hardly uses-- I get that. The
commands that get all the data X,Y,Z position. XYZ angles, 'health' and more.

Those commands are already there and all one needs to plop down their object.
So possibly maybe only a few hardy souls want instanced object spawning- and
the rest won't use it. But it would make for a very high form of potential for the
marketing of MAX, especially when games are made where the player can build up
their own structures *in game* - set up defenses, etc, etc. Show a video of that on
Youtube- and see what positive attention happens!

Also you made a very good point about objects that are already on the map and
get placed in the far corner for later use. Regarding the AI computations, and
the other concerns-- What is the difference between having those pre- existing
objects moved from the far corner to the center of action and just spawning them
anew from the memory there? Both procedures as far as I know would interrupt
the GG style AI path finding, and whatever else seemed important - no?

BTW-- don't we want GG (especially MAX) to really be Game Making for "Everyone!"
and not just the non-coders? Do we intentionally keep the limits down so that all
the creations are still pretty much FPS @ GG AI?

loading map in seprate parts most be added in ggmax at least.

Supe, if you've been watching the GG Max live streams, GG Max will actually support neighboring terrain system so that the map is loaded in parts based on the location of the player.



Kinda possible already in GG. By use of Hiding and turning off collisions. In fact you can even make it so you can build anywhere. For example this fireplace, decal and light source:



I will say however item duplicating in any engine is incredibly handy. We shall see what comes with GG Max in its future.

This is like telling a kid he cant play outside when its raining or cold , but he can play inside the house.
Some kids will do it just to proof a point. lol.

Ps. be careful here is a lot of users here with a inner child in them

Appreciate this gonna come in handy forsure !

Well, I got out an old acquaintance yesterday and cooked this up after a good few hours of playing about.

Looks better in action, but is mostly procedural generated Some better textures and it's almost a ready made shooter Can you guess what it's in?

"I got out an old acquaintance yesterday"
Well, I would guess FPSC but I don't think your procedural level and
possible camera manipulation would be possible without scripts so... IDK?!
AGK? I can't mention other GameMakers on the forum- I don't think?

Dark Basic

@Synchromesh. Yepp you got it although you may have had insider knowledge
DX8 engine and although obviously dated still does most the tings we have wanted for years. I include a demo of it so far, warts and all
AWSD to move Shift to boost speed. I've not added any limits to side movement or tried to make that infinite as well.

Also have to say, people moan about Win 10 but the fact it still runs a DX8 based programming language 20 years on is pretty impressive to me
Edit - It's about 250 lines btw and I could cut that down really. No way you could do it in GG, without having to paste thousands of objects down first. Sometimes coding like this is just easier for certain game styles. DB hasn't actually got anywhere near as many commands as GG, but what's there is much more powerful. I often think if Lee looked at DB again and got at minimum that functionality in GG we would have a better product. DB Pro for the win, although we start getting into many commands again there.

Cannot deny that but I of course I was aware of was aware of fpsc's predecessor

Nice. Sort out a module that contains DB Pro for GG! But I'm sure that
lua can achieve the same when linked to the C++ engine.

Yeah- I don't get the reason to limit commands in a game engine that
relies solely on commands for customized game development?

Look to the past, to build the future.
I didn't have time to mess around with DB pro, so I have no idea how it works, but I'm not sure that it can cover all the new techniques that appear every day in the world of video games.