TIP: Instance vs Prototype
JGary321
Member Posts: 1,246
I posted this in another thread, but thought I would make it more visible & easier to find by creating a Tip thread.
After SIGNIFICANT testing I found that making a separate actor each time for minor changes is a HUGE waste.
In my game I have a mob spawner that acts pretty different based on which level you are playing. It spawns different types of units in different places. I originally had 1 actor for each level. I was always going up to about 58mb memory usage in game & then it would crash. I figured out that the # & weight of ACTORS in your GAME, not just scene, played a HUGE role in how much Ram was used.
So then I used 1 actor & in each instance I copy/pasted all the rules from the original actors in each level. Then I deleted all the unused actors. Now I am consistently around 50-52mb & it doesn't crash. My functionality is the same, but the memory usage went down a lot as you can tell.
My 'thought' is that actors are present in memory at all times, so you can call them up whenever you need to. The instances are only in memory on that particular level, because it doesn't need to be able to call them into place.
Now the obvious issue with doing this is that these now are unlocked & won't be edited by the main actor. But it was such a HUGE memory saver for me that I deem it worth it. Also for me it was fine, b/c those actors are already complete & will not require any changes.
This 'trick' will not help much if you only have one scene though, as the weight of the instance vs actor will be the same (based on my tests).
But in a game with many scenes, not having to load all those actors into memory for every scene really helped my game. I went from crashing before completing one level to playing non-stop without crashes with this one tip.
Hopefully this really helps someone out.
JGary
After SIGNIFICANT testing I found that making a separate actor each time for minor changes is a HUGE waste.
In my game I have a mob spawner that acts pretty different based on which level you are playing. It spawns different types of units in different places. I originally had 1 actor for each level. I was always going up to about 58mb memory usage in game & then it would crash. I figured out that the # & weight of ACTORS in your GAME, not just scene, played a HUGE role in how much Ram was used.
So then I used 1 actor & in each instance I copy/pasted all the rules from the original actors in each level. Then I deleted all the unused actors. Now I am consistently around 50-52mb & it doesn't crash. My functionality is the same, but the memory usage went down a lot as you can tell.
My 'thought' is that actors are present in memory at all times, so you can call them up whenever you need to. The instances are only in memory on that particular level, because it doesn't need to be able to call them into place.
Now the obvious issue with doing this is that these now are unlocked & won't be edited by the main actor. But it was such a HUGE memory saver for me that I deem it worth it. Also for me it was fine, b/c those actors are already complete & will not require any changes.
This 'trick' will not help much if you only have one scene though, as the weight of the instance vs actor will be the same (based on my tests).
But in a game with many scenes, not having to load all those actors into memory for every scene really helped my game. I went from crashing before completing one level to playing non-stop without crashes with this one tip.
Hopefully this really helps someone out.
JGary
Comments
It appears that a significant difference does exist.
Default...
Images: 6.3 MB
Sounds: 70 KB
Game Engine 20.2 MB
Other: 6.5 MB
Total: 33.1 MB
-----------------
Currently unused actors deleted from project...
Images: 3.8 MB
Sound: 0
Game Engine: 18.6 MB
Other: 5.4 MB
Total: 27.8 MB
-----------------------
The difference in FPS was minimal. The number bounces around to much for me to be certain, but there was a huge difference in memory. Actors that are not being used are being stored in memory. That's bad, as the game will crash if enough memory is not available.
I try to keep all of my work restricted to "Prototypes". But unfortunately, it seems that convenience may cause problems for my games
This is from a different thread, but here is the title sequence to my game:
That entire sequence - my logo, the game's logo, the main menu, all the buttons, the lightning, EVERYTHING - was all done with ONE actor.
There are a total of 9 Actor prototypes for the entire game. I have to be careful at all times not to let the RAM spiral out of control. Because I am using so many assets, my RAM usage is always between 31 and 39MB - which is getting dangerously close to the "danger zone" on older devices.
Using instances primarily is certainly difficult to manage, I have to keep copious amounts of notes of where everything is, but it pays off for the end user. The game stays at 60FPS the entire time, and the file size is about 10MB.
Very VERY nice work!
// Red Dot Inc
To be clear, everything in that video is made with just one prototype actor. However, there are twenty or so instances of it. The actor is simply a white box in the library with no graphics and no code. When I drag it out into the Scene, I change its size, position, image, etc. Then I click the padlock to add custom Rules to each one if they require it.
This becomes quite difficult to manage, as I have now broken the prototype-instance bond everywhere - hence all the note taking! It is critical though to be able to pull off this game. If I had a separate prototype for each type of actor, it would add several MBs to the RAM total of each Scene - something I couldn't afford.
If you are just starting out with GameSalad, I don't really recommend it. It's kind of a black art. Several chunks of my code are dependent on the exact layer positioning of the Actors. If those actors are ever accidentally moved to other layers in the Scene, the game will crash - and I will have to hunt through every single instance in the game looking for the problem. Those padlocks are there for a reason, only click them if you know what you are doing.
It's a shame that's the length you have to go to so that you can get the game playable.. I think it's definitely something I will try with my next game as I always try and push myself.
Thanks for the tips
What a nightmare to keep track off. It's all worth it for 60FPS though. The experience is all that matter.
Thanks
JCFord
With this I'm wondering if it would be advantageous to use single actors and just called for different images depending upon conditions. Like if scene is 4, use this image and these rules instead of having so many prototypes.
_________________________________
Nesen Probe: Is this the single most unappealing game in the history of GameSalad? I can't seem to give it away! Anywhere. But if anyone want's to try it out, codes are still available! http://gamesalad.com/forums/topic.php?id=8097
The spawned actors all have different Rules, images, and animations in them. I guess I COULD make them all into one spawned actor separated by Rules, but I would be concerned about the spawn "hiccup" that you get from spawning "heavy" Actors during the game.
So I have 1 generic Actor with no code that I use for pretty much everything in the game.
I also have another generic actor called a "trigger".
I use this Actor throughout the game as well. These instances are used as hotspots in the Scenes.
I have a few hundred of them.
Their Rule sets are generally very simple, like this:
Rule
When Touch is pressed
-----[do something]
The advantage to using a special trigger actor for this is the ability to turn visibility on/off in the prototype. I can turn it on and quickly lay them out over my images, then turn it off again for testing.
The rest of the Actors are all the spawned Actors.
Right now I am getting 60FPS on my 3GS . If I need to, I will try and optimize it further, but it seems pretty solid right now.
Just interested...
_________________________________
My kids think it's so cool their dad has made three fun iPhone apps. I come home from work and they say "Dad, can I get on your iPhone ...and play Angry Birds?"
Just went through my game scene with 0.8.9 and replaced every actor (20 unique) with 1 actor!
I did some rough before and after stats and through just doing this (I plan to go through rigorously to optimise soon) I gained about 8 FPS and 2Mb of RAM!
I'm all organised with the instances too
// Red Dot Inc
@sciTunes: Yeah, I do not do that for the spawned Actors. I mentioned that above, that I think they would cause a hiccup being Rule heavy. My current game doesn't really have a lot of spawned Actors though, only a handful.
BEFORE
Using Multiple Actors
---------------------------------
Loading time: 20 seconds
FPS: 43
IMAGE: 7.1Mb
SOUND: 1.6Mb
ENGINE: 38.9Mb
OTHER: 7.4Mb
----------------------
TOTAL 55Mb
AFTER
Using Single Actor
---------------------------------
Loading time: 7 seconds
FPS: 57
IMAGE: 3.3Mb
SOUND: 15k
ENGINE: 10.6Mb
OTHER: 5.0Mb
----------------------
TOTAL 18.9Mb
Once again thank you joe - I agree this technique is not for beginners, but if anything should be going in the game salad book someone here is writing, then this should be it! Followed shortly by save, save and save again!
I just wonder if there is anything the GS team could do to make this sort of difference without having to do this manually?
JCFord
I am currently working on the iPhone & iPad versions and plan to have it finalised in the next few weeks, here are some of the current screenshots.
Thanks
JCFord
1. MASTER KEYBOARD
2. MASTER BUTTONS
3. MASTER MAGNETS
4. MASTER BACKGROUNDS
The app size it currently 6.1Mb
JCFord
Maybe I'll write some 'black art' tutorials when I get some time!
@rob2: This technique certainly lends itself better to more art-heavy, static games - like puzzle games, or JCFord's game above. But it can be be used everywhere.
The only place it doesn't, is if you are spawning many types of different Actors. It's much easier to have those Prototypes 'ready to go'.
But take my game Danger Cats! for example. All the items that you tap away - EVERY single one, can all be the same Prototype. You can change each one's image, their density, their collision shape, etc.. - all in the Instances. And you don't need to break the padlock for that.
Same thing with all the background elements. They can all be the same prototype as well.
I cannot tell you how many projects I look at from other people, and they have Prototypes like "Background for Level 1" and "Background for Level 2" etc...
That is totally unnecessary. And starts to kill your FPS, as the engine has to carry all that stuff around with it.
@ JGary + FMG
I have to thank you guys. Going back through Kraken, I could see that I already managed to do a lot of what you were talking about.
The backgrounds for each level, for example, have five instances of one actor with different graphics. I think this is a far more effective use of memory than having five different actors (at 1024x512) for each level. So in effect I'm actually doing what you're suggesting to a degree.
Other stuff, like interactive background objects, were individual actors. I've now gone through the game and made them all use one actor - called 'Background prop'. This one actor is used multiple times through each level. I imagine it's helping with memory!
So cheers - I would not have thought of that. I like to traditionally keep things visual, so I can see - oh right, there's the tractor. There's the hedgehog. There's my soul. Having all these three be variants of the same actor hadn't occurred to me!
Cheers for the tip!
QS
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
Also, since actors don't clear from memory when dead (which is ridiculous), does that mean that this way of doing things only loads the actor once? Even if there are 15 instances? Does it just have to load the 15 different images/attributes (if they need to be different)?
This has opened my eyes to a whole new way of game creation...
For some games you could certainly get away with it. For others, not so much. Basically what we are saying is things that are static can easily use only 1 actor. Things that spawn will need multiple actors. There are ways that you could still use one bullet actor for all your bullets.
Just using bullets as an example. This is just a rough example.
Game.Attributes
Bullet = 1
Damage = 10
Speed = 100
In the Bullet Actor you would do rules like this.
(Alpha default is 0)
change attribute image to "bullet(game.bullet)"
change attribute damage to game.damage
change velocity to game.speed
change attribute alpha to 1 <----needs to be last
Then you could have an instance controller that changed the game.attributes when necessary. This way all your bullets are using 1 actor instead of a different actor for each. This also cuts down on the number of total rules in your game.
Again this is a very rough explanation. But hopefully you get the idea. It really wouldn't be too many rules. And like I said you cut down on the OVERALL overhead of the game. EVERY rule you create is creating additional memory requirements.
Hope this helps/makes sense