GMS 2 Is my game too big to succeed?

Here are my problems; please bare with me:

Manually arranging/adding instances and assets in/to my rooms is so laggy at this point that it is becoming nearly impossible... Running and debugging though "successful" take around 12 minutes each time.

Regarding my sprites, they range in byte size between 200 and 800 KB, and their pixel sizes range between 60 x 60 and 800 x 800. I have about 80 of these. A few weeks ago, I was having a problem with these sprites' alpha completely disappearing from the resource tree (icons), sprite and image editors... At that time, they were allocated on 4096 texture pages, and I made certain that they fit appropriately according to their pixel sizes... The disappearing problem finally stopped when I re-allocated much fewer of them to 2048 texture pages. This is strange however because I had lower byte size sprites on the 4096 pages which were 1920x1080. Is there some kind of byte limit that the texture pages have irregardless an appropriate pixel size? Btw, this had been happening on both my Mac and Windows machines —the hardware is not a problem. It would be optimal if I could put as many sprites as I could fit back on to the 4096 pages (without them disappearing).

My rooms are 16,000 x 16,000. I have roughly 5,000 instances based on 60 sprites in each room across 3 layers, and about 1,200 sprites on 2 assets layers as well. So I'm getting the really bad lag when I'm working in the room trying to do simple things (moving things around, etc.). When I open a new blank room, I can move things around very quickly, normally, which —correct me if I'm wrong— seems to indicate that each room has its own cache? What doesn't make any sense is that when I observe my "Activity Monitor" (a Mac app displaying current cpu, gpu, read/write, and memory) my hardware isn't under any notable stress during the periods when I'm trying work in the room.

I got so worried about this that I decided to duplicate one of my rooms x 30 just to see what would happen for a debugging/running. I wanted to know what I'd be in for given that there will be about 300 of these rooms. When I did so, that's where I got the 12-minute cycles noted above. What scares me is that there isn't even any programming attached to these objects yet.

Could someone try to explain what may be happening to my non-programming self?

thx
 

O.Stogden

Member
Not sure about the texture page issues you have, other than the fact that my game has far more than 80 sprites, and I haven't encountered the issues you're describing yet.

As for the rooms, 5,000 instances is an awful lot, none of my rooms have ever come close to that number in the games I've made (I don't think any exceeded 300 or so). It might be an idea to see what you can do to lower that amount, perhaps using draw functions or tiles instead of objects/instances, I can't really see any situation that would require thousands of instances being placed in a room editor. Even a zombie game with thousands of enemies should be done and spawned during gameplay via code, not from within the IDE.

My games usually have a few controller objects placed in the rooms, that then create instances like the player via code, rather than have the player and levels made in the room editor.
 
Not sure about the texture page issues you have, other than the fact that my game has far more than 80 sprites, and I haven't encountered the issues you're describing yet.

As for the rooms, 5,000 instances is an awful lot, none of my rooms have ever come close to that number in the games I've made (I don't think any exceeded 300 or so). It might be an idea to see what you can do to lower that amount, perhaps using draw functions or tiles instead of objects/instances, I can't really see any situation that would require thousands of instances being placed in a room editor. Even a zombie game with thousands of enemies should be done and spawned during gameplay via code, not from within the IDE.

My games usually have a few controller objects placed in the rooms, that then create instances like the player via code, rather than have the player and levels made in the room editor.
Hey thanks for responding! Because of the way I'm doing a very convincing fake 3D game, there just isn't any other choice but for me to use objects the way I've been. As for the amount, that too must remain. I had a couple of thoughts after the original post... Regarding the lag I'm complaining about while working in the room, I think that it may actually be a hardware limitation... My sense is that I'm not really messing with thousands of images as far as my computer is concerned, but one massive image —at one time, just like with the texture pages. Perhaps the texture page can be thought of as on huge image (according to the hardware)...? So with that, The lag will persist and so will disappearing sprites (if too many on one page)...

I'm going to need some kind of simple code/script to tell GMS2 only to draw instances/assets inside of the camera view... I don't know if that would help for debugging/running? I would hope so. I actually posted about that the other day and someone sent me a link to how Forager works. But yeh, 5,000 instance is a heck of a lot, but they're not all supposed to be active at gameplay. There would only be about 120 of them working at once.
 
Last edited:

mikix

Member
Try dividing your texture group into smaller groups. It might help with the runtime. As for the game, yes you need to deactivate everything outside the cameras region for it to not lag.
 

O.Stogden

Member
You can use instance_deactivate and instance_activate functions to turn off instances outside of your view when you're in the game.

Bear in mind that this essentially makes them cease to exist until you activate them though, they won't run any logic, such as collisions or timers when deactivated. Because of that, it's best to have some over-arching controller object that never gets deactivated to handle these, as if the objects themselves handle their own deactivation/activation, they'll never be able to activate themselves, because they're deactivated.
 
Try dividing your texture group into smaller groups. It might help with the runtime. As for the game, yes you need to deactivate everything outside the cameras region for it to not lag.
Thanks for responding! I do have smaller texture groups now, and I think that is what has stopped the disappearing sprites problem. I have a few questions regarding "runtimes," and please again know that I'm not a programmer...
If I were to deactivate everything outside of the camera, does that deactivation include the actual drawing of those instances, or does it still draw them and just disable their code? I would need something that causes them not to be drawn at all. Is what you're pertaining to relate more directly to O.Stogden's latest comment?

Also, When I run debugging in such a situation where my outside-of-the-view instances are deactivated, will that carry over through the debugging or just regular run of the project?
 
You can use instance_deactivate and instance_activate functions to turn off instances outside of your view when you're in the game.

Bear in mind that this essentially makes them cease to exist until you activate them though, they won't run any logic, such as collisions or timers when deactivated. Because of that, it's best to have some over-arching controller object that never gets deactivated to handle these, as if the objects themselves handle their own deactivation/activation, they'll never be able to activate themselves, because they're deactivated.
Could you point me to an easy-to-use tutorial for this? I think that if I just made some kind of command object and then threw all my objects under it as children, this would work right? I just need something simple because I don't code, I just design.
 

mikix

Member
Thanks for responding! I do have smaller texture groups now, and I think that is what has stopped the disappearing sprites problem. I have a few questions regarding "runtimes," and please again know that I'm not a programmer...
If I were to deactivate everything outside of the camera, does that deactivation include the actual drawing of those instances, or does it still draw them and just disable their code? I would need something that causes them not to be drawn at all. Is what you're pertaining to relate more directly to O.Stogden's latest comment?

Also, When I run debugging in such a situation where my outside-of-the-view instances are deactivated, will that carry over through the debugging or just regular run of the project?
It's barely noticeable. I didn't notice that the other objects outside the camera region was turned off when I made a game before. The creeps were all running around anyway.
 
It's barely noticeable. I didn't notice that the other objects outside the camera region was turned off when I made a game before. The creeps were all running around anyway.
I'm confident that there won't be any noticeable emptiness along the edges of the view as the player moves because any instance that is even partly in the view should be drawn with such a command (if that's what you're alluding to)... I'm trying to find out if the deactivation of the outer instances simply deactivates their codes attached while still drawing them, or if it does both? Both meaning no appearance or code. Again, my instances are pretty hefty as it is without code because of the byte sizes of the sprites they're based on. It would make all the difference in my favor to have anything outside of that view not exist... But... Would that also be the case during the debugging, cleaning? That's what it's seeming that I'll need to achieve to cut down those times. And again, as it stands with just 30 of these rooms, I'm at 12 minutes for runs and debugs. And I misrepresented the total number of rooms earlier... There will be 625 of them when I'm done.

Over the past few hours I've succeeded in reducing my template rooms' instances by about 30%. I didn't want to, but again, there was too much lag just trying to arrange things. To give you an idea, when I try to delete an instance from the room it takes about 8 to 10 seconds each time (overloaded). Now, it's still bad, but not completely cumbersome to work on. This is all very nerve-racking because I'm at a point where however it is that I decide to design my rooms will inform everything going forward.
 

kburkhart84

Firehammer Games
I can confirm that if you deactivate an object, it will not draw or run code. That said, I'd like to know what exactly you are doing that has to have so many instances in the room. I feel like there has to be a better way to do whatever it is you are doing, but since I don't know what it is, I can't really suggest what that way would be.
 

relic1882

Member
I had major slowdown with lighting effects in my current project. As soon as I had 40+ lights in my room my fps would tank down to single digits.

I deactivated everything outside of the camera view and used instance_activate_region to activate everything within the player's view, plus an extra amount of pixels off view on each edge in order to keep things looking seemless and not have the lights and enemies activate where you can actively see them spawn in. Fixed all my problems very well.

You want to put the instance deactivate and activate code in an object that's always on screen and moving with you so that the object itself doesn't deactivate and stop activating everything else. In my case, (before I redesigned my camera movement), I put my activation codes within my player because it's always in camera range so the code runs consistent.
 

Joe Ellis

Member
I think one of the main problems will be from having 5000 instances. If hundreds+ of them have draw code or collision checks it'll take a huge toll.
The drawing on the gpu side would probably not be a problem, cus vertices get culled when outside the view region automatically and it can handle millions of vertices being processed in this way. The slow part is texture reading from sprites when their rectangle reaches the pixel shader, so there won't be a problem if you don't have loads of overlapping sprites on the screen at once.
However if 5000 instances are submitting their info to the gpu to potentially get drawn, the vertices get passed to the gpu by the cpu, which will take a huge toll.
Even though you said the hardware isn't under any stress, the problem will be with the cpu but because it only runs on one thread it will only take up one core out of 2, 4+ so it wouldn't seem like it is under stress even though that thread is completely flooded.

I think the solution would be to use some kind of chunking system to load parts as you move through the world. While this is definitely advanced, every large game uses a system like this, it's the only way it's possible.
Or you could split your game\levels into smaller rooms, but it doesn't seem like that kind of game
 
I can confirm that if you deactivate an object, it will not draw or run code. That said, I'd like to know what exactly you are doing that has to have so many instances in the room. I feel like there has to be a better way to do whatever it is you are doing, but since I don't know what it is, I can't really suggest what that way would be.
I can confirm that if you deactivate an object, it will not draw or run code. That said, I'd like to know what exactly you are doing that has to have so many instances in the room. I feel like there has to be a better way to do whatever it is you are doing, but since I don't know what it is, I can't really suggest what that way would be.
No drawing or running code is exactly what I was hoping... Thank you for that info! With that, I'm then confident that my approach will work. The purpose for my having so many instances in the rooms is due to my goal of making a very unique environment with a lot less perceivable repetition than is typical... In other words, the assets will repeat a lot, but their positioning won't so much. And due to the complexity of the assets I've made, and the fact that they will be depth ordered on a single layer, tiles were a no-go. In fact, I don't plan on using any tiles.
 
I had major slowdown with lighting effects in my current project. As soon as I had 40+ lights in my room my fps would tank down to single digits.

I deactivated everything outside of the camera view and used instance_activate_region to activate everything within the player's view, plus an extra amount of pixels off view on each edge in order to keep things looking seemless and not have the lights and enemies activate where you can actively see them spawn in. Fixed all my problems very well.

You want to put the instance deactivate and activate code in an object that's always on screen and moving with you so that the object itself doesn't deactivate and stop activating everything else. In my case, (before I redesigned my camera movement), I put my activation codes within my player because it's always in camera range so the code runs consistent.
Interesting... So I'd have that object being followed just like the player. It could not just simply be placed in the corner of the room.
 
I think one of the main problems will be from having 5000 instances. If hundreds+ of them have draw code or collision checks it'll take a huge toll.
The drawing on the gpu side would probably not be a problem, cus vertices get culled when outside the view region automatically and it can handle millions of vertices being processed in this way. The slow part is texture reading from sprites when their rectangle reaches the pixel shader, so there won't be a problem if you don't have loads of overlapping sprites on the screen at once.
However if 5000 instances are submitting their info to the gpu to potentially get drawn, the vertices get passed to the gpu by the cpu, which will take a huge toll.
Even though you said the hardware isn't under any stress, the problem will be with the cpu but because it only runs on one thread it will only take up one core out of 2, 4+ so it wouldn't seem like it is under stress even though that thread is completely flooded.

I think the solution would be to use some kind of chunking system to load parts as you move through the world. While this is definitely advanced, every large game uses a system like this, it's the only way it's possible.
Or you could split your game\levels into smaller rooms, but it doesn't seem like that kind of game
I'm glad you mentioned this because I'm not the greatest with understanding hardware function to that degree... Here are my readouts from yesterday while waiting for the debug to kick in:
C3.png
C5.png
C6.png
C7.png
Unfortunately, I never took a screen shot of gpu process.

As for chunking, that will be something that my eventual programmer will have to do (way beyond my skill set I think). And you're right about the room sizes... They can't get any smaller due to my design approach.
 
Last edited:

Juju

Member
From experience, tying to wrangle thousands of instances is a bad idea, regardless of whether you're using instance deactivation or not. GameMaker's instances have an enormous overhead. For large, intricate games, an instance-heavy solution is a complete dead-end. Instance deactivation has its uses, but it's not a silver bullet.

For Ditto's Switch release, I replaced our grass instances with sprite assets on layers and held each grass asset as data spread across a couple ds_grids. I termed this a "pseudo object" internally - each piece of grass was still animated and interactive, but they weren't true GameMaker instances. This meant our level designer could have hundreds of bits of grass animated and colliding during gameplay, but we weren't relying on GameMaker's internal objects and collision system at all. This had a substantial positive impact on framerates in multiple systems. The fewer instances you have the faster everything goes, from collision to depth sorting to rendering.

Rather than have the grass check for collision with actors (players/enemies/fire etc.), I checked for collisions from the perspective of the actors instead. These were always going to be fewer in number and, furthermore, all our grass was sitting in a spatial grid so we could check for collisions by reading that grid.

For executing code, we stored a list of "active" grass assets. The active list contained assets that were performing an action of some kind, such as burning or rustling. We added grass to a list if they had been hit by a weapon or were burning, and once a grass asset had finished their action, they were removed from the active list. By limiting which grass assets were we iterating over, we substantially reduced the loop size and thus reduced how much time were we spending handling grass. This is impossible using standard techniques.



As for room editor performance, both HLD and Ditto were created using a custom room editor. This solved a lot of problems, but I wouldn't recommend it for you. Instead, you need to adopt a more innovative approach, one that'll accommodate your goals whilst reducing how much work the Room Editor has to do to render everything.

It's worth looking into how much you can reduce bulk instance placement by using factory instances that build sections of your room by automatically placing assets when the room starts (probably in the Room Start event). For graphical things like trees or leaves, it's not super important that the trees are in an exact position most of the time so this can be done procedurally in code.

With 2.3.0 on the horizon, there's additional option that'll become available. Sequences could be used to break your room down into smaller parts so you can edit each section separately. When a room is loaded, the relevant Sequences are automatically loaded in by GameMaker and - tada - all the instances are in their correct positions. You will have to wait around until 2.3.0 gets released to experiment with this... it's sort of possible to do this already with a subroom assembly system but it's a pain to get that right.



Overall, no, your game isn't "too big", but you do need to adjust the way you're working, and you need to do that sooner rather than later.
 

relic1882

Member
Interesting... So I'd have that object being followed just like the player. It could not just simply be placed in the corner of the room.
Right. If it were placed in the corner, using instance_deactivate_all would shut it off and it would stop working because once you walked away from it, it would not be able to reactivate any more because it's not within the activation region. I made this mistake at first and it took me a moment to figure out why the hell my stuff was activated where the player started but nowhere else. Lol
 

kburkhart84

Firehammer Games
I agree then that you are probably better of doing some chunking as they mentioned above. It seems like I've seen some kind of asset/extension that lets you load rooms in even if you aren't in them. Maybe you could use that to your advantage. The reason I suggest multiple rooms(even if the action happens in a single room) is that you were having problems with the IDE being sluggish too.

You could also make an external editor to handle it. Then you could save all those instances to strings or files and either put that in your code or load in the file, and then not have all of that in the room editor.
 
From experience, tying to wrangle thousands of instances is a bad idea, regardless of whether you're using instance deactivation or not. GameMaker's instances have an enormous overhead. For large, intricate games, an instance-heavy solution is a complete dead-end. Instance deactivation has its uses, but it's not a silver bullet.

For Ditto's Switch release, I replaced our grass instances with sprite assets on layers and held each grass asset as data spread across a couple ds_grids. I termed this a "pseudo object" internally - each piece of grass was still animated and interactive, but they weren't true GameMaker instances. This meant our level designer could have hundreds of bits of grass animated and colliding during gameplay, but we weren't relying on GameMaker's internal objects and collision system at all. This had a substantial positive impact on framerates in multiple systems. The fewer instances you have the faster everything goes, from collision to depth sorting to rendering.

Rather than have the grass check for collision with actors (players/enemies/fire etc.), I checked for collisions from the perspective of the actors instead. These were always going to be fewer in number and, furthermore, all our grass was sitting in a spatial grid so we could check for collisions by reading that grid.

For executing code, we stored a list of "active" grass assets. The active list contained assets that were performing an action of some kind, such as burning or rustling. We added grass to a list if they had been hit by a weapon or were burning, and once a grass asset had finished their action, they were removed from the active list. By limiting which grass assets were we iterating over, we substantially reduced the loop size and thus reduced how much time were we spending handling grass. This is impossible using standard techniques.



As for room editor performance, both HLD and Ditto were created using a custom room editor. This solved a lot of problems, but I wouldn't recommend it for you. Instead, you need to adopt a more innovative approach, one that'll accommodate your goals whilst reducing how much work the Room Editor has to do to render everything.

It's worth looking into how much you can reduce bulk instance placement by using factory instances that build sections of your room by automatically placing assets when the room starts (probably in the Room Start event). For graphical things like trees or leaves, it's not super important that the trees are in an exact position most of the time so this can be done procedurally in code.

With 2.3.0 on the horizon, there's additional option that'll become available. Sequences could be used to break your room down into smaller parts so you can edit each section separately. When a room is loaded, the relevant Sequences are automatically loaded in by GameMaker and - tada - all the instances are in their correct positions. You will have to wait around until 2.3.0 gets released to experiment with this... it's sort of possible to do this already with a subroom assembly system but it's a pain to get that right.



Overall, no, your game isn't "too big", but you do need to adjust the way you're working, and you need to do that sooner rather than later.
Hey, JuJu, thank you so much for your attention and insight. I've run a few comparative tests that I'd like your feedback on:

I opened a new room (16,000 x 16,000) in my project. I set my view to 1920 x 1080. I packed in my objects across 3 layers into that view in the same way that the gameplay would appear full screen. I debugged —which took about 1:15 to get going— and got the following results:
ststs.png

I then opened a new project. I made a tile that was 64 x 64 (solid blue). I made a room 16,000 x 16,000. I made a view of 1920 x 1080. I painted in those view parameters, debugged —which took about 15 seconds to get going— and got back these results:
tilesgo.png

I don't use tiles. I know you didn't suggest them, but they've been suggested to me before as replacement for objects... The only tiles that were used in my last game, "The Yellow Ladder," were just a few collision boxes that my programmer put in. https://store.steampowered.com/app/1130970/The_Yellow_Ladder/

It's safe to say too, however, that the fact that I'm not a programmer means that a lot of times I don't always know "what I don't know."

To be fair regarding this test I ran, none of my objects have any code attached to them yet, but the code that will be attached is pretty basic:

I have 20 different trees. each tree has 3 objects associated them. The first object is the tree image itself—each of those have a shadow attached btw (part of the actual sprite). These tree objects will be programmed to be drawn on top of one another based on their bottom origins. So basically the higher up a tree is placed in a room, lower it will be under a pile of overlapping trees... All of that will be on one layer. The 2nd associated object for each tree is a simple collision barrier. These are designed with the same bottom contours of their corresponding trees and are placed in alignment such that the player and other characters will be blocked from walking through it, but when they move high enough in the room, they will be able to go behind the trees, as they will be programmed with the bottom origin points similarly. The 3rd type of tree objects are basically silhouettes of the trees, but without the shadows. These objects will be programmed such that every time the player or characters walk behind the trees, a colored impression of those characters will appear on an assets layer on top of everything —but the point is that they are still seen normally when they are only under the shadow portions of trees. In my situation, these 3 objects types line up perfectly on top of one another via the 3 layers.

So when you mentioned that the use of many thousands of objects is a "dead-end," could you back that up more (and I don't mean that in any sort of confrontational way)... I just want to make certain "that you're certain" that there is just no possible way that an accomplished programmer can't make this project work in an efficient way based on the approach I'm putting forward... But again, there will be 625 of these rooms with each containing these thousands of tree instances. As for the turf I've created, there are only a handful right now that will just be on an assets layer —no tiles. My turf sprites are 368 x 368 and roughly 400 KB.

Just a side note, wouldn't be possible for my characters to check for tree collisions as apposed to the other way around? Again, there are only 20 tree collision objects...

So now that I've better explained things, what's your take? :)
 
Last edited:
I've now solved the problem of too much lag when working in the room editor by drastically reducing the amount of instances in a given room. I wasn't happy about it because I had to compromise my design in doing some very tedious adjustments, but as of now I have a rough total of 1800 instances in what would be the most dense of my various room templates (as apposed to the nearly-5000)... There is still a lot of lag, but not so much that I can barely work. So at least that part of my problems in mitigated to an extent that I can live with.

As for actual gameplay optimization concerns, I've been studying the "Deactivating Instances" portion of the manual in an attempt to develop a successful way to deactivate instances out of the view.

But my biggest problem still remains... How do I optimize builds? Again, when I make 30 duplicates of my most dense template room, the builds take a really long time. Will this be solved once I develop a system that deactivates all instances outside of the view in all of the rooms, or is that just an optimization approach that only benefits gameplay...? I did pick up on something —I hope— regarding what kburkhart84 suggested ("Then you could save all those instances to strings or files and either put that in your code or load in the file, and then not have all of that in the room editor.")... I was looking in the rooms folders of my project on my desktop, scrolling through the "yy" files. I can see the really long list of coordinates for all of the instances in that room which made me wonder if the reason for the really long build time has to do with fact that GMS2 is filling up my many room editors with all of those sprites. So how exactly do I execute his prescription? How do relieve the room editors during the builds? JuJu suggested the following: "For graphical things like trees or leaves, it's not super important that the trees are in an exact position most of the time so this can be done procedurally in code." In my case, the instances must be in exact position. And that room file I was looking at seems to have them. How do I do this? Again, I'm really hoping that deactivating instances out of the view will take care of this?

thx
 

GMWolf

aka fel666
Hey thanks for responding! Because of the way I'm doing a very convincing fake 3D game, there just isn't any other choice but for me to use objects the way I've been.
This is an immediate red flag to me! You could do a very convincing full 3D game with just one object!
Why does you rendering require more objects?

If you are doing sprite stacking, then please tell me each layer isn't a different object... Use draw_sprite!
 
This is an immediate red flag to me! You could do a very convincing full 3D game with just one object!
Why does you rendering require more objects?

If you are doing sprite stacking, then please tell me each layer isn't a different object... Use draw_sprite!
The great GMWolf has attended my aid, and I sincerely appreciate your time and help Sir! To your first question, I have 20 different types of trees (20 objects). Each of those are associated with 2 more objects which will handle collision and a transparency mechanism. So these many instances are based only on a total of 60 objects... I hope I'm not misunderstanding the point of your question. To the second question, No, there are 3 instance layers... One layer holds the actual trees, and the other 2 layers contain the other associated objects respectively. The purpose of having them on 3 layers is so that I can mark the supporting instance layers invisible.

If "draw_sprite" disregards the placement of these instances in the room editor, the results would ruin my design. Could you be more specific?
 
My suggestion is that you build and test your building blocks in one project, and design levels in another.
Thank you for showing up, Frosty Cat! When you say 'building blocks,' are you just talking about a project without textures and only code? And when the levels (rooms) are finished, how do I incorporate them without the problems I've noted. I know that it's possible to put the room file in "files" in resource tree, but how do I get it activated?
 
This is an immediate red flag to me! You could do a very convincing full 3D game with just one object!
Why does you rendering require more objects?

If you are doing sprite stacking, then please tell me each layer isn't a different object... Use draw_sprite!
I'm revisiting your tutorial for chunks right now.

It is beyond my comprehension as a non-programmer, but the underlying principal makes sense to me.
 

GMWolf

aka fel666
I'm revisiting your tutorial for chunks right now.

It is beyond my comprehension as a non-programmer, but the underlying principal makes sense to me.
Meh I'm not sure I would recommend that tutorial actually. At least, not any of the code it uses.

But the idea of chunking your world would probably help.
As well as using it to store terrain data or tilemap data, you can use it to sort your instances I to chunks.
Each chunk can have a Ds_list of instances.
Then you can use that for efficient deactivation. When a chunk comes into view, activate all instances in it's list.
When a chunk goes out of view, deactivate them.
 

kburkhart84

Firehammer Games
The thing about chunking is that it can also let you design the levels much easier, once you get things going(which would make the slowdown in the IDE no longer be an issue). The best way in my opinion to handle this is as mentioned above, have two projects. One project is the game itself, and the other is the level editor. You could also put them in the same project and just move the folder in the resource tree to make one or the other run, although anything in the level editor that isn't in the game would still be included so you would likely want to use settings to not include them in the builds.

The game would have all the objects for the game, and would use chunking to activate/deactivate objects as mentioned above.

The level editor would also use the chunking in order to make things run smooth. You would have GUI elements that let you create the levels, but in that running project instead of in the room editor. Since it is using the same chunking it would be just as efficient as it would in the game. You can also take advantage of the string serialization of data structures and copy those strings from your real-time level editor and copy them into your code to then load them in at game time. You can probably find some tutorials on level editor creation that would help with this.

If you were to properly split these things up, and get out of using the room editor, I see no reason that you would have any big lag in your game at all, building it, or even editing your levels since you would use the chunking stuff both in game and in the level editor.
 
I want to start this update by thanking everyone who has offered advice here. While I understand the fundamental principles of these solutions, I'll have to pass them along to my eventual programmer to evaluate. As for the interim, the approach that I have been able to take on myself is the building of rooms with room editor in a separate project from the game... But here is the problem: That side project gets slowed down and overwhelmed too.
I'm going to ask a few lay person's questions here which touch on something I'd asked Frosty Cat earlier:

So if I go into my project folder and go to "rooms," and then go to a specific room folder and open that, I have a "yy" file. Here's an abbreviated version of what one of mine look like:


"name": "TurfMixedSet1TEMPTest",
"id": "9275c962-0851-4426-8bfe-4e09fc3aa371",
"creationCodeFile": "",
"inheritCode": false,
"inheritCreationOrder": false,
"inheritLayers": false,
"instanceCreationOrderIDs": [
"96d321ec-9cb5-42cb-aa32-6841fa896b75",
"024aad32-b589-47ee-9729-42b242e8daa3",
"6b30067f-3b11-4cc7-bbcd-d2bc3b54c83e",
"cb2b710e-adf2-4742-b73d-9b3f07cb6dc2",
{"name": "inst_6386ECB0","id": "04665c6a-7fff-433a-9c55-ad6fb9184270","colour": { "Value": 4294967295 },"creationCodeFile": "","creationCodeType": "","ignore": false,"imageIndex": 0,"imageSpeed": 1,"inheritCode": false,"inheritItemSettings": false,"IsDnD": true,"m_originalParentID": "00000000-0000-0000-0000-000000000000","m_serialiseFrozen": false,"modelName": "GMRInstance","name_with_no_file_rename": "inst_6386ECB0","objId": "b496c304-9c59-400f-b3bb-18bff281a905","properties": null,"rotation": 0,"scaleX": 1,"scaleY": 1,"mvc": "1.1","x": 1678,"y": 1842},
{"name": "inst_53A25B58","id": "da57199a-0d21-4a10-84e3-347787b4b42a","colour": { "Value": 4294967295 },"creationCodeFile": "","creationCodeType": "","ignore": false,"imageIndex": 0,"imageSpeed": 1,"inheritCode": false,"inheritItemSettings": false,"IsDnD":
],
"depth": 700,
"grid_x": 368,
"grid_y": 368,
"hierarchyFrozen": true,
"hierarchyVisible": true,
"inheritLayerDepth": false,
"inheritLayerSettings": false,
"inheritSubLayers": false,
"inheritVisibility": false,
"layers": [

],
"m_parentID": "00000000-0000-0000-0000-000000000000",
"m_serialiseFrozen": true,
"modelName": "GMRAssetLayer",
"mvc": "1.0",
"userdefined_depth": false,
"visible": true
},
{
"__type": "GMRBackgroundLayer_Model:#YoYoStudio.MVCFormat",
"name": "Background",
"id": "4d1d3fe5-833d-4a1f-8905-57640868cb2b",
"animationFPS": 15,
"animationSpeedType": "0",
"colour": { "Value": 4284897597 },
"depth": 800,
"grid_x": 16,
"grid_y": 16,
"hierarchyFrozen": false,
"hierarchyVisible": false,
"hspeed": 0,
"htiled": false,
"inheritLayerDepth": false,
"inheritLayerSettings": false,
"inheritSubLayers": false,
"inheritVisibility": false,
"layers": [

],
"m_parentID": "00000000-0000-0000-0000-000000000000",
"m_serialiseFrozen": false,
"modelName": "GMRBackgroundLayer",
"mvc": "1.0",
"spriteId": "00000000-0000-0000-0000-000000000000",
"stretch": false,
"userdefined_animFPS": false,
"userdefined_depth": false,
"visible": false,
"vspeed": 0,
"vtiled": false,
"x": 0,
"y": 0
}
],
"modelName": "GMRoom",
"parentId": "00000000-0000-0000-0000-000000000000",
"physicsSettings": {
"id": "6af46896-c30c-4680-a149-f3405a945fe9",
"inheritPhysicsSettings": false,
"modelName": "GMRoomPhysicsSettings",
"PhysicsWorld": false,
"PhysicsWorldGravityX": 0,
"PhysicsWorldGravityY": 10,
"PhysicsWorldPixToMeters": 0.1,
"mvc": "1.0"
},
"roomSettings": {
"id": "70cff6ca-5869-4f6c-88db-c58866a8919c",
"Height": 24000,
"inheritRoomSettings": false,
"modelName": "GMRoomSettings",
"persistent": false,
"mvc": "1.0",
"Width": 24000
},
"mvc": "1.0",
"views": [
{"id": "f1ffcdf4-5301-49b8-a811-1728b5a180fd","hborder": 32,"hport": 1080,"hspeed": -1,"hview": 1080,"inherit": false,"modelName": "GMRView","objId": "67916bd1-624a-434d-9798-81698e6e60cd","mvc": "1.0","vborder": 32,"visible": true,"vspeed": -1,"wport": 1920,"wview": 1920,"xport": 0,"xview": 6000,"yport": 0,"yview": 6000},
{"id": "f35f3c84-3980-4704-831d-4a83bb740a00","hborder": 32,"hport": 768,"hspeed": -1,"hview": 768,"inherit": false,"modelName": "GMRView","objId": "00000000-0000-0000-0000-000000000000","mvc": "1.0","vborder": 32,"visible": false,"vspeed": -1,"wport": 1024,"wview": 1024,"xport": 0,"xview": 0,"yport": 0,"yview": 0}
],
"viewSettings": {
"id": "b7a67ceb-548e-4244-918d-b2e6d1578475",
"clearDisplayBuffer": true,
"clearViewBackground": true,
"enableViews": true,
"inheritViewSettings": false,
"modelName": "GMRoomViewSettings",
"mvc": "1.0"
}
}


So I had to trim most of the creation order Ids because it was too long to be accepted... But I've put in the critical stuff (I think).
So let's turn the attention back to how I've been putting my rooms together... I've been using the room editor to place each individual object and asset where they should go, but only regarding x,y values. There will eventually be a command put forth to make these objects appear on top of one another based on the heights of their respective bottom orientations (I didn't want to say "depth order" because that is a programming term and I'm not certain that it means what I think it does). And so here are my two questions:

Lets' take the room for which this code represents as an example: What if I went into this room's editor and removed all of the assets and objects that were placed, but I kept the room and it's name as such that it is in the top of the code... Is it not possible that this code can be placed somewhere else —as I think was suggested— and activated to draw this whole room's contents? This I think would fix the bad bog downs of my runs and work periods (in the room editor). And if this is the case that this can be done, what about the depth ordering thing I mentioned? Could a script be added to this room code doc which changes the depths, but keeps the x y values of everything?
If these things can be done, then this should solve the problems? I could go to each room and clear them out and then this code could just run the room?

I know and I feel your pain that this is stupid stuff perhaps, but again, and I always say this: I'm no programmer. I'm in the weird in between space where I work in the IDE but subcontract out the programming. So let me know, am I thinking correctly, and most importantly, can that depth be changes from a simple script, or would each id have to be changes manually?
thx
 
There may be some wild workaround to this, but in general, no, it's not possible to grab the data from the .yy file and put it INTO an object in GMS somewhere and have it run.
 
There may be some wild workaround to this, but in general, no, it's not possible to grab the data from the .yy file and put it INTO an object in GMS somewhere and have it run.
Where does the code exist that draws things placed in the room via room editor...? Or maybe there isn't any code for that because I did it by had draggin it all in there?
 

chamaeleon

Member
Where does the code exist that draws things placed in the room via room editor...? Or maybe there isn't any code for that because I did it by had draggin it all in there?
It's all compiled into the game, probably sitting in more efficient data structures that may bear no resemblance to the project file on disk.
 
It's all compiled into the game, probably sitting in more efficient data structures that may bear no resemblance to the project file on disk.
Hmmm. I may just have to make about 40 or so different projects to build my rooms and then stick those in the main game folder and have their rooms called as was earlier suggested. I just don't have enough cache on my machine to do it any other way in the interim.
 
The thing about chunking is that it can also let you design the levels much easier, once you get things going(which would make the slowdown in the IDE no longer be an issue). The best way in my opinion to handle this is as mentioned above, have two projects. One project is the game itself, and the other is the level editor. You could also put them in the same project and just move the folder in the resource tree to make one or the other run, although anything in the level editor that isn't in the game would still be included so you would likely want to use settings to not include them in the builds.

The game would have all the objects for the game, and would use chunking to activate/deactivate objects as mentioned above.

The level editor would also use the chunking in order to make things run smooth. You would have GUI elements that let you create the levels, but in that running project instead of in the room editor. Since it is using the same chunking it would be just as efficient as it would in the game. You can also take advantage of the string serialization of data structures and copy those strings from your real-time level editor and copy them into your code to then load them in at game time. You can probably find some tutorials on level editor creation that would help with this.

If you were to properly split these things up, and get out of using the room editor, I see no reason that you would have any big lag in your game at all, building it, or even editing your levels since you would use the chunking stuff both in game and in the level editor.
Could you clarify this a bit more regarding the approach of using one project to control another? I'm going to try this, but I need confirmation that this will actually work before I start the process... I'm going to make about 40 or more different projects with each containing about 15 of my huge rooms. Then I will have the actual game project controlling the other projects when needed? You discussed putting the folder of another project in the resource tree of the main game, is that right? The resource tree does not seem to accept entire project folders... "Extensions" and "Included Files" only accept single files. How precisely would this work?
Fundamentally, I just need to be able to spread my rooms across different projects until I hire a programmer to take care of the stuff that is over my head, i.e. the chunking and so on. I would need an iron-clad guarantee that these will all be able to operate together. And when I say that I'll need a "guarantee," please know that I mean that in a respectful way; it just has to be a sure thing given how long it takes me to organize a single room (for which there will be 625 or more).
thx
 

kburkhart84

Firehammer Games
Whether you use the same project to store both the editor and the game, or you separate them, you will still have to come up with a way to transfer the data over. I've seen serialized data structures used, which could be copy/pasted as strings into code directly. You could also come up with a file format, and then load those from the included files(which only let you load one at a time into the IDE but after that are generally just fine). Which way works best for you will depend exactly what data you need from the editor to get transferred to the game. I don't know those details so I don't know the best way and can't offer a suggestion.

1. Create the editor and game in the same project. This carries the issue that unless you delete the editor resources(like graphics, etc...) each time you want to build the game, it will contain the resources from the editor as well. It doesn't really affect it because you can simply put the game's first room on top...but it IS extra resources regardless, which will end up in your final project possibly. In order to use the editor, you will end up wanting to select the editor's first room as the first room of the build/game, and then run it, or build it. Then it will have all the game's resources, many of which don't belong in the editor(though some do). This can technically work, but to me it feels like more of a pain to deal with.

2. Create two separate projects for game and editor. This allows your game to have the full resources it needs, and your editor to have only what it needs. If your editor is being used for placing things in the room, you can display those with a single frame of the sprite, and then when your game uses them, it would of course use the full animations and objects as needed. And it would be easy enough to build either the game or the editor at any time without worrying about which room is first, or the extra resources in either one.

As far as spreading your rooms across different projects...that's not the idea I'm going for. I'm going for having only a single room that is your game room, and then loading the data, objects, etc... for wherever you are into that room when you start. Then, as you move around, it unloads things that are farther away, and loads things in as you get closer to them. That's what "chunks" are. I would say you could have 9 such chunks loaded at a time in a grid of 3x3 with you in the middle one. If you move to the top center, it would unload the bottom 3 and load in the top three. It could in fact do that over time instead of all in a single frame if you crafted it that way. The reason you load 9 instead of just the 5 without the corners is so if you are on the very edge it doesn't trigger loading too much all at once. Then, your editor could use that same system to display the whole world all at once, loading in/out what is needed. You would also need to devise how you are going to store those chunks, if you use data structures, arrays, or even raw buffers that you format to your liking.

So yeah, I can't make any guarantees at all for you. It is up to you how you program this thing, or if you hire someone, or how it gets handled. But putting separate rooms in separate projects in not what I talking about, except for the separation of game from editor rooms specifically(I'm not sure if that's what you meant).
 
Whether you use the same project to store both the editor and the game, or you separate them, you will still have to come up with a way to transfer the data over. I've seen serialized data structures used, which could be copy/pasted as strings into code directly. You could also come up with a file format, and then load those from the included files(which only let you load one at a time into the IDE but after that are generally just fine). Which way works best for you will depend exactly what data you need from the editor to get transferred to the game. I don't know those details so I don't know the best way and can't offer a suggestion.

1. Create the editor and game in the same project. This carries the issue that unless you delete the editor resources(like graphics, etc...) each time you want to build the game, it will contain the resources from the editor as well. It doesn't really affect it because you can simply put the game's first room on top...but it IS extra resources regardless, which will end up in your final project possibly. In order to use the editor, you will end up wanting to select the editor's first room as the first room of the build/game, and then run it, or build it. Then it will have all the game's resources, many of which don't belong in the editor(though some do). This can technically work, but to me it feels like more of a pain to deal with.

2. Create two separate projects for game and editor. This allows your game to have the full resources it needs, and your editor to have only what it needs. If your editor is being used for placing things in the room, you can display those with a single frame of the sprite, and then when your game uses them, it would of course use the full animations and objects as needed. And it would be easy enough to build either the game or the editor at any time without worrying about which room is first, or the extra resources in either one.

As far as spreading your rooms across different projects...that's not the idea I'm going for. I'm going for having only a single room that is your game room, and then loading the data, objects, etc... for wherever you are into that room when you start. Then, as you move around, it unloads things that are farther away, and loads things in as you get closer to them. That's what "chunks" are. I would say you could have 9 such chunks loaded at a time in a grid of 3x3 with you in the middle one. If you move to the top center, it would unload the bottom 3 and load in the top three. It could in fact do that over time instead of all in a single frame if you crafted it that way. The reason you load 9 instead of just the 5 without the corners is so if you are on the very edge it doesn't trigger loading too much all at once. Then, your editor could use that same system to display the whole world all at once, loading in/out what is needed. You would also need to devise how you are going to store those chunks, if you use data structures, arrays, or even raw buffers that you format to your liking.

So yeah, I can't make any guarantees at all for you. It is up to you how you program this thing, or if you hire someone, or how it gets handled. But putting separate rooms in separate projects in not what I talking about, except for the separation of game from editor rooms specifically(I'm not sure if that's what you meant).
I want to make certain that I'm not misunderstanding what you and others are referring to when discussing "editor." You're/they're talking about the vertical window on the left side of the IDE containing layers, room size, views, etc., or is it a custom-made programming tool being proposed? If the former is the case, How could one have a game project without its room editor? If a new programming tool is what's being suggested here, this would have to be something that I'd subcontract out. Regarding anything programming-related, these tasks will be given to the programmer; but your proposals, nor any others' would be lost on this thread, as I'd be pointing that person to this dialogue when the time comes to devise an approach. But for this interim, I hope to finally settle on a "flexible" basis to work from in preparing this project for that next endeavor...

Because of the fact that I'm assembling my rooms by way of dragging in objects/instances, assets, it seems that the only retrievable data representing those arrangements exists in the yy room files from the actual project folder. RefresherTowel mentioned that that info could not generally be put into an object to create a room (paraphrasing), but perhaps there is another means of data transfer that you were alluding to which could be done with this? These big slow downs in loading/building the project are due exclusively to the massive amount of instances/assets in the rooms, as well as that there are so many rooms —and there will be a great many more. So even if I were to go the single-room route using chunks, the fact remains that the rooms I'm composing either have to exist across numerous projects, somehow being transferred in/activated, or each time I compose a room in a single project, I make a copy of that yy room file from the project folder and then go to its respective room in the IDE and delete all of the instances/assets that I'd dragged in. RefresherTowel suggested that there may be some kind of workaround to do the later. Out of at least these two approaches, I'm certain that I'd prefer the former because as my assembling of this project continues, I'll most likely need to revise aspects of these many rooms via IDE... It would be nearly impossible to do so post a mass deletion of instances/assets in the rooms with only their respective yy room files left over, as I'd need those as visual reference points to make compositional edits... The yy room files are just code (I know that you guys know that, but I wanted to make sure that you all knew that I myself knew that).

So given all of that, and for the sake of pure speculation (not argument), let's agree to agree that having numerous projects containing these many rooms is probably the least efficient way to do this (and zany too probably)... But I'm beginning to see that given my circumstances, it might be the only way. Can this work? If I take this route, will there be an available way perhaps for an eventual programmer to put these projects together, however convoluted such a process may prove to be? I want to stress that I'm not just being contrarian or anything like that (and not that I necessarily think you or others think that of my questions either)... I just want to get across that I respect programmers and their insistence on doing things in the most efficient ways possible. But again, and in at least these technical points discussed outside of the many other considerations that go into efficient production, "efficiency" here may have to be left by the wayside for me to realize my goal.

Also: Please ignore these two attachments. They got stuck in some kind of uploading limbo, but the point I'd been trying to make with them was made in written form.
 

Attachments

Last edited:

kburkhart84

Firehammer Games
By editor, I personally am referring to an editor that would be a separate thing from Gamemaker, likely created with Gamemaker(though could be created elsewhere). That's why I'm saying to separate the editor project from the game project, as they are two different things.

About using the editor(as I'm defining it), you would actually use that INSTEAD of Gamemaker's room editor to lay out your levels. Then, the room editor in gamemaker would only have whatever objects are needed to load those levels in. If you are considering an external editor like this, I'm not sure how you would be worrying about using the room editor, and doing different projects for each level...makes no sense to me.
 
By editor, I personally am referring to an editor that would be a separate thing from Gamemaker, likely created with Gamemaker(though could be created elsewhere). That's why I'm saying to separate the editor project from the game project, as they are two different things.

About using the editor(as I'm defining it), you would actually use that INSTEAD of Gamemaker's room editor to lay out your levels. Then, the room editor in gamemaker would only have whatever objects are needed to load those levels in. If you are considering an external editor like this, I'm not sure how you would be worrying about using the room editor, and doing different projects for each level...makes no sense to me.
I'm not going to be using an external editor to make my rooms. I'll be using the room editor. I just need to know if it will be possible to spread the rooms across numerous separate projects and them have them pulled together later on? I'm worried about the room editor now because I'm currently working in only one project (which is bogged down from so many rooms. I don't have problem with the room editor itself, just too many rooms in one project.
 

chamaeleon

Member
I just need to know if it will be possible to spread the rooms across numerous separate projects and them have them pulled together later on?
Sounds like a terrible workflow that GMS is not well suited to. What do you expect "pull together" to be, exactly? Export/import local package? Surely not messing around with the file structure of GMS projects outside GMS itself.
 
Sounds like a terrible workflow that GMS is not well suited to. What do you expect "pull together" to be, exactly? Export/import local package? Surely not messing around with the file structure of GMS projects outside GMS itself.
I was of the belief that if it's possible to have one project run another, why not be able to have one project run many... I'm just trying to find out if it's possible. Whatever programming approach that makes it happen, I don't know. I'm not a programmer. My guess is that the whole thing would need to be published as local in the end (if I'm thinking about it correctly).
 

kburkhart84

Firehammer Games
No, as far as I know you can't have a project run another. That's why I keep bringing up the idea of using an external program(even if you make it in GMS) as the level editor. You can have your rooms stored as files, or strings, or some kind of buffer or data structure, instead of having to have all that bulk in the room editor and all those rooms(since since it seems this is what's slowing you down).
 
No, as far as I know you can't have a project run another. That's why I keep bringing up the idea of using an external program(even if you make it in GMS) as the level editor. You can have your rooms stored as files, or strings, or some kind of buffer or data structure, instead of having to have all that bulk in the room editor and all those rooms(since since it seems this is what's slowing you down).
Ok. Thanks for bearing with me. I think that I have a clearer understanding now. I'm going to try a few bizarre and unorthodox things and will report back to the thread with whatever those findings end up being.:)
 
I have an update here and would greatly appreciate some advice regarding the approach I'd like to take...

And for the purpose of getting these ideas boiled-down within a single post without anybody really needing to read so many earlier parts of this thread, I'll just offer a brief recap of my situation, along with what I'm changing:

I have a project which will eventually contain 625 rooms with each room containing roughly 2000 instances that are based on 60 different objects . Due to my chosen design approach, all of these instances are placed strategically in each room by way of my dragging them in (settled matter). And due to the density of so many resources being put into the rooms, my load times began reaching 10 minutes or more with only about 40 of the rooms completed... And the build times were a lot worse.

So here are the two problems: How to I continue adding these dense rooms to this huge project without the very sluggish loads, and how do I run/debug the project without the very very "sluggish" build times?


Actually, both of these "problems" are solved, but their respective solutions need to be reconciled...

The long loading time problems have been fixed by my separating the project into multiple projects where I'm dealing with fewer rooms per project at a time. I now have 25 projects with each containing only 25 rooms. These projects only take about 30 seconds to load.

The long build times and low fps, etc. "will" be solved when an eventual programmer creates code which will draw only the objects in view.

Right now, I'm able to go to the "rooms" creator area of the resource tree, select "Add Existing," and simply choose the "yy file" from a room in a different project. That room shows up "fully furnished" in the resource tree... And so this is how this all may go once all of my rooms are designed in these various projects... But here is the main problem, and where I need advice... Due to the fact that the programmer would be using code to control the drawing of all of these instances in an efficient way, what will become of working in the IDE when we're not running/debugging. Will there be a way that we could evaluate these various rooms "one by one" when necessary without the terrible loading times for the project? What happens when all 625 rooms are finally part of the main project? or is this where Kburkhart84's suggestion comes in where the rooms from external projects are brought in as strings somehow? And in such a case, the rooms in the separate projects would have to be dealt with separately when things need to be changes in them... For example, If I wanted to add or remove instances, I'd have to go to the room in that separate project because all 625 rooms couldn't possibly exist in one project's IDE?

thx

EDIT: And what also confuses me is why my hardware cannot handle the loads in the first place given the fact that I have 64 gb of ram and it only peaks at around 14 gb of use during loading... The CPU and GPU don't seem to ever be under pressure either during this... I don't know. :confused:
 
Last edited:

kburkhart84

Firehammer Games
This is why I mention creating your own level editor, which would then save your levels as strings, instead of insisting on using the room editor at all. If you insist on creating that many rooms like this, even if in separate projects, you are going to have to put them all together at some point in order to finally make a build. If you would make a level editor, it wouldn't even need the optimization of the run-time because all those objects wouldn't be dong anything, and would instead be simple placeholders doing nothing but drawing a graphic so you see where it is.

Once all your levels are made up of strings instead of rooms, then you can easily have only one room handle the levels and just load up the correct string. 2000 instances really isn't that much IMO, so you may not have too much of an issue, especially once the programmer adds some code that deactivates the objects that are too far away from the player to matter.

About your hardware not handling it....it very well could simply be Gamemaker that can't handle it. I understand that the IDE is a 64-bit application and doesn't have limits on the RAM it accesses because of that(though the runner is still limited to 32bit architecture). So maybe it is simply the IDE itself that can't keep up...I don't know, and I never tested it to see what it would do on my PC either.
 
This is why I mention creating your own level editor, which would then save your levels as strings, instead of insisting on using the room editor at all. If you insist on creating that many rooms like this, even if in separate projects, you are going to have to put them all together at some point in order to finally make a build. If you would make a level editor, it wouldn't even need the optimization of the run-time because all those objects wouldn't be dong anything, and would instead be simple placeholders doing nothing but drawing a graphic so you see where it is.

Once all your levels are made up of strings instead of rooms, then you can easily have only one room handle the levels and just load up the correct string. 2000 instances really isn't that much IMO, so you may not have too much of an issue, especially once the programmer adds some code that deactivates the objects that are too far away from the player to matter.

About your hardware not handling it....it very well could simply be Gamemaker that can't handle it. I understand that the IDE is a 64-bit application and doesn't have limits on the RAM it accesses because of that(though the runner is still limited to 32bit architecture). So maybe it is simply the IDE itself that can't keep up...I don't know, and I never tested it to see what it would do on my PC either.
I don't know how to make a level editor... Plus, I'd already done too much work with the room editors by the time I'd begun this thread. I would be set back many weeks if I were to start over. But then again, perhaps a programmer would somehow be able to easily, efficiently convert those various rooms from various separate projects into custom level editors to make these strings prior to bringing everything to the main project...? If not that then yeh, they would have to bring each room into the main project from the separate projects one by one... That would take a good half of a day, and any adjustments with the rooms' contents would have to be done within their respective separate projects since they can't be viewed with everything drawn in (dragged in) in the main. So much of this is about my attempts at mitigating loss of time and energy while trying to strike a balance with efficiency and what's actually doable.
I'm still holding out hope that strings —or something similar— could be made with those yy room files given that all of the instance IDs/placements are there... It would seem that all that would be necessary to accommodate those is that their respective rooms and layers are present in the main. There has to be a way, I would think. Perhaps a script could run those? What in those yy room files is NOT contained that would be needed to make them work?

I never knew about the runner architecture being 32 bit. I've tried my massive project on both Mac and windows machines (both very capable)... Maybe it's an optimization thing with their OSs.

But anyhow, maybe someone for the heck of it would like to experiment with their yy room files to see what the limits might be in making a room with them in some backwards way. If that file is sitting somewhere in code or in "included files" then you might have all you would need to draw a curated room's contents without those contents just sitting there soaking up the program's/system's juice as does the regular way? :)

EDIT: I was just re-reading the first paragraph of your May 16th post in this thread regarding the file format/data structure ideas, so that gave me some hope that what I'm trying will not be a lost cause.
 
Last edited:
I'm not saying definitely abandon your train of thought and restart the process with a better foundation (though, I would be very tempted to) but definitely beware of sunk cost fallacy. Losing a few weeks can definitely be worth the cost if it means that future edits are done quickly and easily in a better environment. Many times I've powered through with a very sub-optimal way of doing things and then come across a point where I literally cannot progress without rewriting everything. If I had of done that when I first realised that my method was sub-optimal, I would've saved time in the long term by doing the rewrite at that point and then quickly working my way back to the point where I was, instead of forging ahead and then, later, having to do exactly that anyway but with MORE time wasted.
 
I'm not saying definitely abandon your train of thought and restart the process with a better foundation (though, I would be very tempted to) but definitely beware of sunk cost fallacy. Losing a few weeks can definitely be worth the cost if it means that future edits are done quickly and easily in a better environment. Many times I've powered through with a very sub-optimal way of doing things and then come across a point where I literally cannot progress without rewriting everything. If I had of done that when I first realised that my method was sub-optimal, I would've saved time in the long term by doing the rewrite at that point and then quickly working my way back to the point where I was, instead of forging ahead and then, later, having to do exactly that anyway but with MORE time wasted.
Point taken, definitely, and thank you, RT. I think that in my case the most likely area of additional wasted time —if I were to stick with the current plan— would be my having to go into the rooms in the various projects to make curatorial edits... And although that would be a bit more difficult for me to do as apposed to having all of the rooms in one place in a custom editor, it would perhaps mean extra grief for the programmer to get that newer info back into the main project. So even without a set plan for programming, the prospective burden on my end is something that I could live with, but what lies ahead for the programmer may be a tougher situation (and I don't say that lightly). But the more I think about it, the more I realize that if I were to start over with a custom room editor, I'd need to learn that tool and be really confident. This would mean that the programmer would have to hold my hand through a lot of that learning curve... And knowing myself and how over-my-head these things tend to be, my budget could start to evaporate... In other words, I fear that I would become the "bottleneck," and to the detriment of more aspects in the endeavor than I'd be willing/able to account for. So I suppose this is me trying to convince myself to follow through with the current "shot in the dark" (with which I have more confidence and understanding) as apposed to another prescription that might throw off the whole project due only to my lack of abilities, time, and funds. Ultimately, I think that the right programmer will be able to compensate for these root logistical challenges without me in the way (to the extent that I'd be if I were to start over).
 
Last edited:

kburkhart84

Firehammer Games
Me personally...I don't want to sound rude of course, but this is the kind of thing you probably should have planned for ahead of time. I get it though, that originally you didn't know you were going to have the issues in the first place(I wouldn't have known either). However, I would say that it is likely worth it to go ahead and spend time creating that level editor, and possibly having to redo the levels all in that editor. The biggest thing to make the decision...can you get it done the way you are doing it right now? If so, realistically, how long will it take? And, if you spend a few weeks creating a level editor and redoing the levels in it, would the time then saved on creating the rest of the levels in your new level editor, and the time saved by trying to import rooms from different projects, the possibly be less? If the time delays you are running into with the room editor having that many instances, and the build times, are as bad as you make it out to be, I'd be willing to estimate that the level editor will make things worth it in the long run.

Besides solving the current problem, there is also a consideration, that the level editor could be the start of something you can simply modify for a different project if you needed it. Also consider if you do it nicely, your players could make their own levels too, which could be the start of mod support.
 
Me personally...I don't want to sound rude of course, but this is the kind of thing you probably should have planned for ahead of time. I get it though, that originally you didn't know you were going to have the issues in the first place(I wouldn't have known either). However, I would say that it is likely worth it to go ahead and spend time creating that level editor, and possibly having to redo the levels all in that editor. The biggest thing to make the decision...can you get it done the way you are doing it right now? If so, realistically, how long will it take? And, if you spend a few weeks creating a level editor and redoing the levels in it, would the time then saved on creating the rest of the levels in your new level editor, and the time saved by trying to import rooms from different projects, the possibly be less? If the time delays you are running into with the room editor having that many instances, and the build times, are as bad as you make it out to be, I'd be willing to estimate that the level editor will make things worth it in the long run.

Besides solving the current problem, there is also a consideration, that the level editor could be the start of something you can simply modify for a different project if you needed it. Also consider if you do it nicely, your players could make their own levels too, which could be the start of mod support.
You don't sound rude at all my friend, and thanks for the attention to this thread. The load times/run times are not a problem anymore give that I've made separate projects... But again, I don't know how to make custom level editors. I'm just going to go forward the way I've been and then have a programmer pull it all together when I'm done with my side of the project.
 
Last edited:
Top