Your talk of instances and prototypes is confusing. An actor in a scene is always an instance of a prototype. The only other type of actor is an unlocked instance so what exactly do you mean by 'converting prototypes to instances' were you unlocking actors or adding them to a scene?
I actually have tiles... four for each level... 512x512. That's because GameSalad doesn't accept images larger than 1024x1024. The larger images are needed for retina display graphics. So, a 1024x1024 area uses four 1024x1024 images.
I created a prototype actor for each one of those images. So far, that's 64 prototypes.
I thought that might be contributing to the extra loading time, but it's not. When I created a single prototype actor called "Blank", and manually populated each scene with instanced actors, it seemingly had no effect on performance.
The images are too big.
I know this because of the main base. It actually uses only two large images. It loads faster than the other scenes.
But here's what's weird... where's all that loading coming from? Is it image compression? With The Unofficial GameSalad Textbook app, there's no loading time to change pages. Those images pop right up.
So... what is GameSalad doing with the PNGs?
Meanwhile, do I redo all of the game artwork with tiny tiles? If the images are too big, then there are only three choices...
1 - Redo the artwork, making it smaller 2 - Leave the loading times 3 - Abandon the project.
A fourth choice is to drop retina display... not going to happen.
Here you go buddy, this has cut my loading time to under a second, it's almost instant...
Have everything as just a standard White actor with nothing as the image (this does make editing your game tricky andnthe scene layers section becomes your best friend, unless you do this at the end, buti never though of that until now so I'm just navigating through the sea of White squares). The first rule in the actor change image to the image you want.
I already did. I wasted five hours doing that. Surprisingly, it didn't work. The blank prototype actor... four white squares in scenes with a change image behavior... it didn't seem to change the loading times.
I'm wondering if a recent change to GameSalad makes it unnecessary to use the prototype/instancing trick.
I think I have a solution. It involves tiling the artwork and creative use of those tiles... similar to the way I fixed the clouds.
This...
• Dramatically changes the level design • Adds an insane amount of work • Makes the game a lot more fun • Eliminates scene loading
The plan for the rest of the day is to test this radical change. I'm not sure if this idea is going to work. If it works, I basically added about a 1-2 weeks to the project... but I'd be saving lives with no loading times!
tenrdrmerMember, Sous Chef, Senior Sous-ChefPosts: 9,934
Load times to the viewer are not going to be consistent with load times of an actual build because it is basically going through the motions of building the game each time you load to the viewer. so I wouldn't make massive changes unless you have done an ad hoc an are not happy with performance there. I'm not sure I would consider the viewer reliable for testing at the level you are probably at. You should prob start doing daily adhocs for beta testing.
tenrdrmer said: Load times to the viewer are not going to be consistent with load times of an actual build because it is basically going through the motions of building the game each time you load to the viewer. so I wouldn't make massive changes unless you have done an ad hoc an are not happy with performance there. I'm not sure I would consider the viewer reliable for testing at the level you are probably at. You should prob start doing daily adhocs for beta testing.
tenrdrmer said: Load times to the viewer are not going to be consistent with load times of an actual build because it is basically going through the motions of building the game each time you load to the viewer. so I wouldn't make massive changes unless you have done an ad hoc an are not happy with performance there. I'm not sure I would consider the viewer reliable for testing at the level you are probably at. You should prob start doing daily adhocs for beta testing.
The "recent games" is similar to an actual game though.
I'm not so worried about the initial loading... which is only 3 seconds. It's the 3-4 seconds between each level. I think I can avoid that. It's a lot of work, but I think it makes the game a lot better.
tenrdrmerMember, Sous Chef, Senior Sous-ChefPosts: 9,934
Even the between scene stuff or the entire gameplay could be different in an actual build. Please tell me you have done some adhoc testing with being this far in. You've been around long enough to know the view doesn't fully represent how the game will play.
I think AdHoc is unnecessary. I think playing a game in the viewer — as a "Recent Game" — is sufficient. When comparing a final game to a game in the viewer, it's basically the same.
Loading times are long. Large images are the cause. I'm working on it.
Photics said: I think AdHoc is unnecessary. I think playing a game in the viewer — as a "Recent Game" — is sufficient. When comparing a final game to a game in the viewer, it's basically the same.
Wow... AdHoc was amazing. Five seconds after creating a provisioning profile, my computer started completing the project for me. When I ran the testing app, the frames per second were at 120... double the limit. TANK had a fifth gun that I didn't even create. There were now 70 levels, and they all loaded so fast that I went back in time. Fortunately, BOT rewrote my version of iOS to allow trans-dimensional messaging. Apparently, the AdHoc version of my app became self-aware. It figured out quantum computing and worm hole tunneling. Also, as a side effect of AdHoc testing, I'm no longer human. While holding my iPhone during testing, I was transformed. You may simply refer to me as "The Entity" currently existing in Winner, South Dakota (circa 1958).
Oh wait... none of that actually happened. Reality was more like this...
3:06 PM - Testing Provisioning Profile Created 3:12 PM (Approximately) - Upload began 3:29 PM - Still waiting for upload to finish
Photics maybe you could try changing the size of your background images to a much smaller size so it's not loading that large of an actor and then have a rule that swaps image and adjusts the size of the actor too. I haven't tested this but it might work.
GamersRejoice said: I haven't tested this but it might work.
I'm already in the process of testing it. I split up my backgrounds into 256x256 images for 128x128 actors. Each actor is a tiles... 64 per scene. The idea is that about 20 actors will surround TANK, changing position as the background tile leave from view... somewhat like Michael Jackson in the Billie Jean video.
3:35 PM - still waiting for the project to finish uploading
Now I'm wondering, is the GameSalad team looking at my game? Heh... the beauty of cloud computing. Somewhere in Austin, "Wow... he wasn't kidding... this game is good." ...or... "Wow, I thought the game would be better."
Here's what's confused me about tiles. It's an old web trick to reduce the size of your pages by breaking up the images into slices. I thought 64 256x256 images would be smaller than 4 1024x1024 images. Nope!
Heh, this seems like an uphill climb the whole way.
tshirtbooth said: I repeat to everyone. Making an adhoc build is one of the most important things you can do.
I agree with the general idea that testing is important... but this is actually the first time I've used AdHoc. And as expected... it did nothing... except waste another hour.
tenrdrmerMember, Sous Chef, Senior Sous-ChefPosts: 9,934
Photics said: I agree with the general idea that testing is important... but this is actually the first time I've used AdHoc. And as expected... it did nothing... except waste another hour.
It was only long because of the size of your app. Thats why I said once a day. The viewer is good basic testing little changes and stuff. not playing the whole game through.
I know you see it as a waste but wouldn't it be much more of a waste when you have spent months working on this only to find out after you published it that something doesn't work. I hope you have all the devices you plan to support so you can test also. cause every app even plays a little different on each gen of device. Galactic.Towers was pretty easy to beat on a 3g but on the iphone 4 some of the levels were nearly impossible because it all played differently.
Do what you want man but your in way to deep to not be doing at least one adhoc a day IMHO.
I got the answers to the questions. It doesn't seem like any top-secret stuff, so I'm posting it here...
1 - What is GameSalad doing when it's compressing assets?
GameSalad compresses only images in a format that is still viewable by iOS devices. That is as much as I can reveal.
2 - Where does scene loading come from / Why does it take so long?
Scene loading takes a while because of new images and actors being loaded. If images used on the next scene exist in the current scene, there is less load time. Also unloading of images not used in the next scene.
3 - How can I improve scene loading times?
Try to use assets that are used in the next scene. Or don't have too much on the next scene.
4 - What if GameSalad didn't compress assets, would the game run faster?
Not sure. It might run slower. Assets are compressed while the game is packaged. The compression still allows the image to be seen by the device.
5 - I'm using ImageOptim to compress my images. Should I be using that or is GameSalad compressing PNGs for me?
GameSalad is compressing it for you.
There are not too many surprises. Although, there were two things that I found interesting.
1 - Unloading of images, I didn't even think that was an issue. 2 - ImageOptim is a waste of time, unless you want to save some hard drive space.
1a - Does unloading of images significantly add to loading times? 1b - If so, would using "Change Image" to a blank image speed things up?
2a - Instances vs Prototypes... Does having too many Prototypes add to loading times and/or damage game performance? My testing suggests that it doesn't, but many in the community think that it does help apps run better.
The answers to these questions help the community. Heh, not having to run ImageOptim certainly changes things.
I improved the loading times. It's 50% better... like 2 seconds... I think this an acceptable level. That's only one human death every 70 days. HA HA. Well, that's a very negative way of looking at it. This is a two-second opportunity to clean the sweat and finger gunk from the screen... like the rest between rounds in a boxing match.
If you absolutely hate loading times, then the Mac version might be better for you.
When I started figuring out how to implement the "Billie Jean" tiling system, I realized these extra actors would create a lot of problems. Do I really want 40-60 constraints for 20 tiles? What happens if Rules misfired? So, I started looking for better solutions.
Here's what I noticed...
If I wrapped the "Change attribute" in a .1 second "After" timer, then I would actually see a loading time decrease.
It's a bunch of garbage actually. Why can I load large images instantly while the scene is running, but performance suffers if the images are set beforehand? GameSalad should fix this.
Also, I noticed that my invisible actors are causing loading delays. For testing purposes, I set it to alpha zero. This is so I can see where the invisible actors are while building the level. Strangely, this seemed to add to the scene loading time. When I switched from Alpha Zero to Graphics Invisible, the loading times improved.
This highlights three issues with GameSalad.
• Image loading is flawed. Developers are doing extra work to compensate. • An image cannot be deleted from a prototype, unless you go into XML. • GameSalad should have a mode where an actor's physics shapes are shown, so it's easier to work with invisible actors.
BOT is back on track. Loading times are still an issue, but it's downgraded to a yellow issue from a red issue. I have a clear shot to the second week in May - supposedly when Game Center will be added to GameSalad.
tenrdrmerMember, Sous Chef, Senior Sous-ChefPosts: 9,934
Also, I noticed that my invisible actors are causing loading delays. For testing purposes, I set it to alpha zero. This is so I can see where the invisible actors are while building the level. Strangely, this seemed to add to the scene loading time. When I switched from Alpha Zero to Graphics Invisible, the loading times improved.
This has been known for a long time. if you want to save on performance set as many actors as you can to non-movable and invisible. if its visible it uses image resources even if its alpha and if its movable it will load physics attributes when not needed.
Correction: The last update was April 27, not April 20.
April 28, 2011 - Progress Report
Loading, please wait!
So, I'm still having loading problems, but of a different sort. As I write this, a new level is rendering. I think it looks great. I'm wondering if I should split it up and add some parallax scrolling, something the game is lacking. More depth would be nice.
The loading times are dramatically improved.
Instead of putting a collide behavior on the invisible wall and hole actors, which was multiplied by 60 times (approximately) per scene, I put the collision behavior on TANK.
Earlier, my concern was that there were too many behaviors on TANK. I tried to split things up by putting some of the behaviors on other actors. Apparently, that was a bad idea.
I was playing through the game yesterday and it felt big... and that's without enemies and a solid understanding of the game's layout. I think when a player is first introduced to this world, it might feel very overwhelming. That's good!
I watched 127 hours last night. The backgrounds reminded me of my game... one guy wandering around this vast landscape of rocky terrain. It's a great movie and it's based on a true story! When the exploring guy gets trapped by the big rock, I started thinking about the similarities to my game development. I often feel like I'm stuck to my computer, unable to free myself until I finish this game.
Fortunately, my situation is not as dramatic. It's a cloudy day outside — perfect for game development. I have plenty of food and I'm fairly comfortable. But if BOT is a success, I'll probably buy a new chair. This one is starting to wear out. A piece of metal sticks out, right where my right leg is.
Anyway, the rendering is done — less chatting and more working!
Is something ever too good? That was always a strange saying to me... "Don't try to be too good." Shouldn't we always strive to do better, to be better?!
Well, after a month of creating levels for BOT, I'm starting to get really good at it. If you're been following along, you might have noticed that I'm not entirely happy with the levels. They're good, but I think they can be better. Today, I finally created a level that I was extremely satisfied with.
The difference ——— parallax scrolling!
When I entered the level, after changing the colors and fixing problems with my math, it was jaw dropping. I just looked at it in astonishment... "WHOA!". That's right, like Neo in the Matrix, I actually said, "WHOA!"
The other levels were good, but this new level is "too good". It's so far beyond what I've done before that it doesn't quite fit in the game. I have to go back redo some of my levels, raising the quality of the level design.
Parallax scrolling makes a huge difference... HUGE... ENORMOUS!
Even if you're making a top-down game, you can still add layers of scrolling. Earlier today I was busy figuring out the math. I wanted to create a sense of depth, but I didn't want to kill the performance.
MISSION ACCOMPLISHED!
Heh, but I just created a lot more work for myself.
Comments
I created a prototype actor for each one of those images.
So far, that's 64 prototypes.
I thought that might be contributing to the extra loading time, but it's not. When I created a single prototype actor called "Blank", and manually populated each scene with instanced actors, it seemingly had no effect on performance.
The images are too big.
I know this because of the main base. It actually uses only two large images. It loads faster than the other scenes.
But here's what's weird... where's all that loading coming from? Is it image compression? With The Unofficial GameSalad Textbook app, there's no loading time to change pages. Those images pop right up.
So... what is GameSalad doing with the PNGs?
Meanwhile, do I redo all of the game artwork with tiny tiles? If the images are too big, then there are only three choices...
1 - Redo the artwork, making it smaller
2 - Leave the loading times
3 - Abandon the project.
A fourth choice is to drop retina display... not going to happen.
Have everything as just a standard White actor with nothing as the image (this does make editing your game tricky andnthe scene layers section becomes your best friend, unless you do this at the end, buti never though of that until now so I'm just navigating through the sea of White squares). The first rule in the actor change image to the image you want.
Try that mate.
Ace
I'm wondering if a recent change to GameSalad makes it unnecessary to use the prototype/instancing trick.
This...
• Dramatically changes the level design
• Adds an insane amount of work
• Makes the game a lot more fun
• Eliminates scene loading
The plan for the rest of the day is to test this radical change. I'm not sure if this idea is going to work. If it works, I basically added about a 1-2 weeks to the project... but I'd be saving lives with no loading times!
Ace
I'm not so worried about the initial loading... which is only 3 seconds. It's the 3-4 seconds between each level. I think I can avoid that. It's a lot of work, but I think it makes the game a lot better.
Loading times are long.
Large images are the cause.
I'm working on it.
Oh wait... none of that actually happened. Reality was more like this...
3:06 PM - Testing Provisioning Profile Created
3:12 PM (Approximately) - Upload began
3:29 PM - Still waiting for upload to finish
3:35 PM - still waiting for the project to finish uploading
3:42 PM - Fireworks
WOW...
It's...
IT'S...
IT'S...
...exactly the same.
Now I'm wondering, is the GameSalad team looking at my game? Heh... the beauty of cloud computing. Somewhere in Austin, "Wow... he wasn't kidding... this game is good." ...or... "Wow, I thought the game would be better."
Here's what's confused me about tiles. It's an old web trick to reduce the size of your pages by breaking up the images into slices. I thought 64 256x256 images would be smaller than 4 1024x1024 images. Nope!
Heh, this seems like an uphill climb the whole way.
I know you see it as a waste but wouldn't it be much more of a waste when you have spent months working on this only to find out after you published it that something doesn't work. I hope you have all the devices you plan to support so you can test also. cause every app even plays a little different on each gen of device. Galactic.Towers was pretty easy to beat on a 3g but on the iphone 4 some of the levels were nearly impossible because it all played differently.
Do what you want man but your in way to deep to not be doing at least one adhoc a day IMHO.
___________________________________________________________________________________
Project Help from Tenrdrmer Click Here
GS BubbleBall Template HERE!!
Stacks Level Selection Template HERE!!
Expanding Option Menu Template HERE!!
Tenrdrmer's Menu # 3 HERE!!
Menu #4 - Level Banners HERE!!
AppSolute Entertainment on Facebook
AppSolute Entertainment on iTunes
1 - Unloading of images, I didn't even think that was an issue.
2 - ImageOptim is a waste of time, unless you want to save some hard drive space.
1a - Does unloading of images significantly add to loading times?
1b - If so, would using "Change Image" to a blank image speed things up?
2a - Instances vs Prototypes... Does having too many Prototypes add to loading times and/or damage game performance? My testing suggests that it doesn't, but many in the community think that it does help apps run better.
The answers to these questions help the community. Heh, not having to run ImageOptim certainly changes things.
I'm going to go try that!
I should have known, but I forgot. The "Change Image" behavior might be pre-loading the images... RESULTING IN NO CHANGE!
This doesn't make any sense. Change Attribute had the same basic result as Change Image.
The prototype vs instance thing is supposed to work, but it doesn't for me.
--------
GameSalad answered my questions. As suspected, image unloading is basically nothing... and Prototypes don't really mess up loading.
I'm going to try the Michael Jackson thing.
Victory!
I improved the loading times. It's 50% better... like 2 seconds... I think this an acceptable level. That's only one human death every 70 days. HA HA. Well, that's a very negative way of looking at it. This is a two-second opportunity to clean the sweat and finger gunk from the screen... like the rest between rounds in a boxing match.
If you absolutely hate loading times, then the Mac version might be better for you.
When I started figuring out how to implement the "Billie Jean" tiling system, I realized these extra actors would create a lot of problems. Do I really want 40-60 constraints for 20 tiles? What happens if Rules misfired? So, I started looking for better solutions.
Here's what I noticed...
If I wrapped the "Change attribute" in a .1 second "After" timer, then I would actually see a loading time decrease.
It's a bunch of garbage actually. Why can I load large images instantly while the scene is running, but performance suffers if the images are set beforehand? GameSalad should fix this.
Also, I noticed that my invisible actors are causing loading delays. For testing purposes, I set it to alpha zero. This is so I can see where the invisible actors are while building the level. Strangely, this seemed to add to the scene loading time. When I switched from Alpha Zero to Graphics Invisible, the loading times improved.
This highlights three issues with GameSalad.
• Image loading is flawed. Developers are doing extra work to compensate.
• An image cannot be deleted from a prototype, unless you go into XML.
• GameSalad should have a mode where an actor's physics shapes are shown, so it's easier to work with invisible actors.
BOT is back on track. Loading times are still an issue, but it's downgraded to a yellow issue from a red issue. I have a clear shot to the second week in May - supposedly when Game Center will be added to GameSalad.
April 28, 2011 - Progress Report
Loading, please wait!
So, I'm still having loading problems, but of a different sort. As I write this, a new level is rendering. I think it looks great. I'm wondering if I should split it up and add some parallax scrolling, something the game is lacking. More depth would be nice.
The loading times are dramatically improved.
Instead of putting a collide behavior on the invisible wall and hole actors, which was multiplied by 60 times (approximately) per scene, I put the collision behavior on TANK.
Earlier, my concern was that there were too many behaviors on TANK. I tried to split things up by putting some of the behaviors on other actors. Apparently, that was a bad idea.
I was playing through the game yesterday and it felt big... and that's without enemies and a solid understanding of the game's layout. I think when a player is first introduced to this world, it might feel very overwhelming. That's good!
I watched 127 hours last night. The backgrounds reminded me of my game... one guy wandering around this vast landscape of rocky terrain. It's a great movie and it's based on a true story! When the exploring guy gets trapped by the big rock, I started thinking about the similarities to my game development. I often feel like I'm stuck to my computer, unable to free myself until I finish this game.
Fortunately, my situation is not as dramatic. It's a cloudy day outside — perfect for game development. I have plenty of food and I'm fairly comfortable. But if BOT is a success, I'll probably buy a new chair. This one is starting to wear out. A piece of metal sticks out, right where my right leg is.
Anyway, the rendering is done — less chatting and more working!
Too Good!
Is something ever too good? That was always a strange saying to me... "Don't try to be too good." Shouldn't we always strive to do better, to be better?!
Well, after a month of creating levels for BOT, I'm starting to get really good at it. If you're been following along, you might have noticed that I'm not entirely happy with the levels. They're good, but I think they can be better. Today, I finally created a level that I was extremely satisfied with.
The difference ——— parallax scrolling!
When I entered the level, after changing the colors and fixing problems with my math, it was jaw dropping. I just looked at it in astonishment... "WHOA!". That's right, like Neo in the Matrix, I actually said, "WHOA!"
The other levels were good, but this new level is "too good". It's so far beyond what I've done before that it doesn't quite fit in the game. I have to go back redo some of my levels, raising the quality of the level design.
Parallax scrolling makes a huge difference... HUGE... ENORMOUS!
Even if you're making a top-down game, you can still add layers of scrolling. Earlier today I was busy figuring out the math. I wanted to create a sense of depth, but I didn't want to kill the performance.
MISSION ACCOMPLISHED!
Heh, but I just created a lot more work for myself.