Load time culprits
Ok, I managed to test and figure out some things causing load times. I put my hypothesis to the test, and lo and behold, managed to reduce a large level loading from 45 seconds, down to 8 to 12 seconds!! On an android device no less!!
Some things I changed where reducing code, not preloading art, and MUSIC variety. I use play sound to play ogg orbis songs, and each level had the choice of 4 different songs. Now, I remember reading somewhere that because of the way something works, that any music connected to a scene will be loaded, even if its not used. So I set the songs to play on their own actors, with that actor appearing in it's respective level.
That last modification managed to reduce the load time from 45 to the 8 to 12 seconds I got now. Before, I managed to reduce it down from 60 seconds after reducing some code and not preloading art.
Now, I know it can load much faster than this, after realizing that menus in the game still load within 2 seconds each. After one of the playable levels still took 12 seconds despite being barren of graphics except for the player character and a single enemy{and the level itself being the size of a menu scene.;}
It dawned on me that the code within the actor is the last part still causing load times, as that is the difference between that barren level, and a menu with several HD graphics, but actors nearly empty of code. The sages and gurus on this forum aren't kidding when they say code makes the difference in performance, I thought they just meant during runtime, but I didn't think it would drastically effect load time.{Each player character has a TON of behaviors within them to allow all the fancy stuff done in the game, each of the characters are on average, half a megabyte.}
The enemies would be the actors around the 200 kb range, they use to be 100kb less when their only A.I. was full on attack. When I gave them the ability to switch between two different sorts, it increased their size somewhat.
Which is why I was attempting to get rid of the old damage system, right now, they just have those behaviors turned off and the new damage systems on for testing purposes. Which should hopefully drop their size greatly once the two other systems are deleted.
Anyway, what it all comes down to is SIZE of the file. For every megabyte of data loading, wether if its an actor, image, or sound, it appears that an entire megabyte takes a few seconds to load?
Perhaps somebody can do the math, but quickly, I can guess somethings here. When the load time was recently at 45 seconds after optimizing other things. The last thing left to optimize was music at this point. Because of the music variety, and each song being 2mb on average. It was a total of 8mb being loaded along with the half mb to quarter mb actors, a scene in total might be 12mb previously.(2mb more for the four characters, unless actors not used are not loaded, even if they are referenced in the behavior. And another 2-3 mb of enemies referenced in code as well, since the existing enemies are each 100-300kb.} If load time went down from 45 to 12 after removing 6 mb of preloaded sounds, that would mean loading an entire megabyte takes 3 to 5 seconds on average?
If I had 12mb of data to load in a scene, and if each mb is 3.8 seconds(guess from device loading) of load time, then that would equate to 45.6 seconds. Which falls into the previous load time I observed before the sound per scene reduction.
From knowing all this, a form of "best practice" can be made for GS, to ensure games load quickly and efficiently.
I want to note that when the load time was at 60, another test I did was cutting all graphic sizes in half. The load times were reduced down to 20-30 seconds.
If I tried that now with the new load time, I could probably have a better performing game{the game did perform very fast during runtime even with lots of enemies, while with the original sized graphics, it would run smooth if the level only had 1 or 2 enemies on screen, but more than that, and some noticeable frame drops can be seen, just slightly.{Not enough for me to notice , but I wonder how players would react if playing on the device version?}
Anyway, has anybody gone in depth into what effects load times?
Do tables affect load times drastically if referenced in a scene?
I've been thinking of recreating the actor, but due to all the connected game attributes, I feel like I might get lost, break something, and be in the mud trying to figure out where I went wrong due to the amount of features each character has. {The screenshot with the actors in order of size, the top actor is Phreit Nor, as he has so many advanced things like screen panning when he shoots and the ability to have the screen follow a decoy.
Comments
Thank you for your insights this is helpful! I actually created a rule that will play a handful of my most common sounds at zero volume (at the beginning of the scene) which seems to have helped FPS, as well as preloading a select few actors.
I'm currently trying to get loading times down though and hoping I can identify the source of the problem. I tested deleting actors one by one and such but nothing glaring stood out and pre-load is turned off for pretty much all of my actors.
Would also like to hear from you/others what exactly a code cleanup should look like (e.g. is it just a matter of having less behaviors overall?)
POLAR ROLLOUT (New Line-Drawing Physics Puzzler!) - FREE Download
@supafly129 You're welcome. Hopefully, GS can find the real culprit that is causing these load times if they are not meant to be this long.
Now you understand the benefits of integrated efficient code. I never have load time issue. I rearely use music files unless I want the music to continue across scenes. That is the only reason to use music over sounds. Writing good code takes time to learn. Why? Because you need a real grasp of all the possible methods to do things. You need to know many methods on how to do something as well as being able to create your own methods. Most people don't take the time to learn properly. The get GS and just rush into making games and the cycle continues. I spent a year not making games and just learning GS and built tons of prototype projects. This is how I am able to write such slim code. You have to experiment and take time to think out your code. You see this unfold with veteran members on the forum guys like @socks, @jamie_c, @RThurman, @Armelline et.. Are constantly experimenting with better methods to do things. This is the same with me. I may come up with ten different versions of my code before I find the most refined method.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
@Lost_Oasis_Games Yes, I do now understand the benefits of integrated efficient code. I didn't even understand that all those behaviors and rules had actual weight in terms of bytes. A lot of newcomers might not understand this too, and will probably end up creating some fancy stuff, but use too many rules for it.
Even now, I seldom use "else" despite it's high potential for compartmentalizing code in favor of making another rule to cover a more specific or opposite value.
Yeah, I should have spent at least three months learning about integrated code before starting on the game.
Although, I may appreciate it, I'm still lacking in the skill neccessary for handling code{especially if I had just made art within the past 2 hours, which puts my brain in a mode that prevents me from understanding logic for a bit/makes me blank minded}, I wrestled for days with making a shop that utilizes the same table as an inventory menu, while being able to add and subtract from said table, then having a system that prevents that when a gem is in "use", as well as the gem itself modifying parameters using random() and table cell values.
Example table:
One of the Expressions being used to modify player stats with a gem via accessing data on the table, from a post I did yesterday:
game.AttackGem +( game.AttackGem *(random(tableCellValue( game.InventoryTable , self.ItemType , 3),tableCellValue( game.InventoryTable , self.ItemType , 4))))
>
How it looks in game{the randomly placed, color coded numbers are to make sure everythnig is working, for example AG is the value of the gem once activated, the 0/1 over the gem graphic shows if a gem is actively in use or not.
Perhaps I could have done it more efficiently, and with a smaller table. {I was informed in the other thread that random() doesn't work with decimal numbers.
I'll make sure to study integrated logic before re-making everything for the sequel.
This is a very common experience with new comers to GS. I can't even count how many times people have come on the forum after working on a game for months to report how slow and laggy their game is and have to go back and do a major overhaul. We with experience try to tell people the advantages of taking it slow when first learning and starting out small and build up a level of experience. This solid advice is usually ignored because the desire to jump in and build a big exciting game is hard to resist. It usually doesn't end well and many give up in frustration. Our advice simply comes from experience of making the same mistakes ourselves. The difference is we didn't quit but stopped and took the time to properly learn the software so we can make solid games at a faster rate. This is why a veteran can wip you up a prototype in 5 minutes.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
@Lost_Oasis_Games Very true indeed, I went through most of that.
The game performs well on a desktop supported platform, but right now, on mobile, aside from the 12 second load time for the actual game{menus load quick, due to minimal rules.} There is a strange "Stuttering" that occurs when damage calculations using the new system occurs. It can't be seen on PC, since the cpu is powerful enough to make the gameplay smooth{and give instant to 2 second load times even for the main scenes.}
Here is some gameplay footage for one of the characters:
Like I mentioned earlier, on mobile, anytime a bullet hits, the screen shakes violently/stutters rapidly. This didnt' happen before on the plain damage system, which used simple substraction.
The old system which didn't lag was long and simple, but a clumsy list of rules. Just having a simple self.hp minus arbitrary number for 30+ attacks.
The new attributes involved, narrowed the entire thing down to a single rule, as well as giving the player the ability to modify their attack and defense levels with the gem and self powering systems{no defense in the old version, just pure 100hp - arbitrary, non-game attribute number.}
The new system looks like this{you can see where game.attackgem is used}:
The enemy sides involves these stats:
Thus, the enemy makes the final damage calculation before applying it to it's hp, after taking in game.totalattackpower into consideration, which that game attribute is finalized by the player character for the enemy character to take into account for determining how much attack power it was damaged by.
The system works well on robust platforms, but it's in-efficiency shows itself on android mobile. As a strange stuttering occurs, or instead, a lag spike if the player spawned below them in the layer order. {Trying to confirm though, as the lag spike/no stutter only really happened when the enemies where already placed on the map, and didn't spawn after the player, even if they are higher in the layers.}
On advice on something else, would it be wiser if I just stick to art? All the art you see in the game was made by me, from the menu art to the sprites. Perhaps I should leave the logic assembly to somebody else and share the profits{Rayburst was intended to be a group effort, despite the solo start.} I already have somebody doing the music.
I'm thinking life is about teamwork. Being a jack of all trades or mastering a lot of things only makes sense if I was immortal, lol. But my limited lifespan suggest I make the best use of that time, and try to accomplish things much faster/more efficiently by instead relying on others for help, for example, somebody that specializes in something I'm only moderately okay at, such as logic handling. I'd be glad to sign a fair agreement/share in the profits. That's what I'm thinking right now, lol, since I think I should really use this time to improve the graphics of the game, add more frames of sprites to make more fluid animations, and so on. I'm tempted to post that in the help wanted section.
I think I've come as far as I can with logic building, and this is the best I can do. {It is fun trying to solve it, and learning it, but I might end up doing less overall.} That is the drawback of time.